Refactoring Bittersweet PHP: How can I make this less painful?

Question

I've just been assigned a large project. The client has had multiple developers across different companies working on their (intended to be) large, MySQL driven eCommerce site.

The DB schema is ...pretty good, naming is a bit rendundant but nothing real bad.

The real issue is the code is in desperate need of "OOP-ification". Sadly, while actually being fairly nice procedural code as far as simplicity and legibility, there are so far about 3 functions across...about 50 files. :( Thankfully these are handling database connection but there's not a single function, class or even a foreach anywhere in site that deals with page rendering.

All static using implicitly defined php variables and some js. Tons of reduncy and inconsistent use of code vs. html. File/directory structure is probably the worst of all :/

The client very very much needs a custom CMS, especially for inventory control. Dynamic page generation is a must but I doubt they will want me to start over.

So I ask: is there a point of attack that will make transforming this code into a more straightforward task?

Answer 1

Funny, I just answered something similar to this in this thread.

In a nutshell, the client won't care what the code looks like so really, you shouldn't either.

I would highly suggest developing new features using today's OO standard approaches and only refactoring legacy code when absolutely needed.

If the client wants to pay you for refactoring time further down the road (or you just want to take the time yourself), then have at 'er. But, I assume they're not paying you for that - they're paying you for additional features.

Whenever you refactor code, there's always the possibility of introducing knock-on bugs. If you're refactoring code just for the sake of refactoring and the client finds problems in the output, you're going to have to answer some tough questions as to why you did it (and again, management and clients don't care that the code looks better or is easier to work with).

Answer 2

One of the possible points of attack without a rewrite from scratch is to start out with code-duplication detection which allows for minor variations, for instance with phpcpd. It can make the first steps obvious quickly.

Answer 3

Actually, from my experience it would be better if you start writing it from the scratch... If the requirements won't allow you to do so, the project will probably fail. At least it will be like late. And by late I mean it would take like 3 times what is scheduled.
My sincere sympathy.

Answer 4

Software Engineering isn't just a discipline of writing code; it also requires the ability design and test what you are creating. Similarly, refactoring isn't just about changing lines of code, you also need to introduce great design and great tests.

Without great tests, you'll start playing whack-a-mole with bugs - you'll never be able to reach the confident ideals of refactoring mercilessly if you need to keep stopping to work out what you've broken. What's worse, you could lose business confidence by introducing bugs into production. To this end, great automated tests are vital. Fortunately, even if your code is not yet object-oriented or has anti-functional design, you can always implement automated tests. Creating a test suite of browser regression tests is always possible and I highly recommend you do so for features before you refactor the code behind them.

In terms of the design part; refactoring can start with a process of simply renaming variables and methods so they accurately describe what's going on. Splitting long methods and classes into smaller ones is also a perfectly logical step in identifying Code Smells. As your confidence in the codebase develops, you can start ensuring your code converges towards Object-Orientation and SOLID principles. However, remember that refactoring isn't a process you should seek to finish - as you add more features to your code base, the need to refactor mercilessly will not end. You should always seek to ensure your codebase is as simple and readable for the job at hand.

I've gone into detail with the technologies and the processes you can use to achieve this, alongside some common pitfalls, in a blog post I recently wrote: Refactoring Legacy PHP