I have a slightly old PHP project I’m working on for a client (I think it was started around 5 years ago), it makes extensive use of the outmoded mysql_query function, which is concerning not only because it’s now deprecated but because it could also open security holes.
The project doesn’t seem to have much of a structure either, I think the original developer had some kind of method when working on it, but there’s no documentation and I’m not able to get in contact with him regarding said project.
As I’ve been going through I’ve been switching the database queries to use PDO, and trying to clean things up a little, but it’s quite a big project (a few hundred php files) and I don’t want to spend too much time restructuring things at it detracts from the time I’ve got allotted to this each month.
What should I do? Would a rewrite be a good idea? Or should I simply try and re-mold the current project into something a little nicer?
1
Unless you are introducing an existing framework into the code and 90% of the original code will be taken over by the framework, doing a big rewrite will almost certainly cost more time than incrementally refactoring the code.
If the original code is essentially good (well documented & structured), but just not according to today’s best practices, then you won’t gain much by restructuring it and you might as well keep the original structure also for the new features (consistency across a codebase is far more important for maintainability than following the latest best practices).
If the original code is not really all that good, but you don’t have the time/resources to fix it all at once, then you could tackle each month a small portion that irritates you the most or that hinders you in implementing some new features.
I would have to recommend the advice of Martin Fowler on this one.
When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
In other words, refactor as needed when you need to make a change. This keeps you from getting entangled in a massive refactoring for the sake of refactoring, while providing a justification to refactor when you need to refactor.