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?


4 Answers 4


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).

  • Very much what I would like to do. This client is going to be long long long-term (in theory). This site has been in the works for 2.5+ years and it still can't do anything but load about 12 products...I haven't even found a loop anywhere...scary.. Anyway, they do want the current form to work. I'm trying to come up with some way to separate design and data while turning long, drawn out, loopless sets of queries into something coherent. le sigh. Apr 28, 2011 at 19:30
  • One big thing is that I'm going to be working with this same site 2 years down the line most likely. I would really like to be able to maintain it without editing 20 files each time I want to update a part of the display x_x; Apr 28, 2011 at 19:36
  • 1
    @garet: Maybe look at cheap, easy (with an emphasis on cheap) win ways to encapsulate as much of the functionality as possible.. All I can say other than that without knowing the code base is.. Good luck :) Apr 28, 2011 at 19:41
  • Eventually, this is what actually had to happen. I had forgotten about that project but you were certainly right. I have since well drawn the line where I must rewrite or throw out. Sep 17, 2012 at 3:25

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.

  • I think I do alright with php for a C++ guy, but I really haven't gotten into many optimization/debugging tools yet. Thanks much for this! Apr 28, 2011 at 19:31

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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.