Originally published at: http://www.sitepoint.com/modernizing-legacy-applications-php-review/
Chances are you’ve come across some horrible legacy code once or twice in your lifetime as a PHP developer. Heck, if you’ve worked with WordPress to any degree, I’m sure you have. I myself have had the satisfying task of modernizing a monolithic ZF1 application, and it was the most mentally exhaustive (but, admittedly, the most educational) year of my career.
If only I had had Paul M. Jones’ “Modernizing Legacy Applications In PHP” book back then, I would have been done in half the time, and the work I did would have been twice as good.
Many thanks to Paul for providing me with a review copy after having read my review of Design Patterns in PHP. The book is a Leanpub publication – meaning it’s self-published – but that’s where similarities with other Leanpub content I’ve consumed so far end.
Modernizing Legacy Applications in PHP is a detailed step by step guide in turning a spaghetti mess of old PHP code you’ve probably inherited from a team that left two generations ago, into a sort of fully fledged MVC application with the front controller, router, dependency injection, and even unit tests.
Continue reading this article on SitePoint
I bought this book several months ago and I can attest to how good it is. Along with Working Effectively with Legacy Code by Michael Feathers it has been a great reference tool for working with the projects I have had.
It hasn’t been directly applicable to the code I have had to deal with which has been old Code Igniter projects where the developers had no idea what MVC or DRY or any best practices are. But the ideas behind the steps and methods to pull logic from the madness has helped immensely.
Personally, the best thought I’ve taken away is to not take on a monolith monolithically. Work at chipping away at it and not a full rewrite from scratch.
Right now I read Working Effectively with Legacy Code by Michael Feathers. That’s a really great book. How does Modernizing Legacy Applications in PHP compare to it?
I’ve just read the free sample available on Leanpub, and I did not like it. I did not like the writing style, the advice given was correct, but the description of the steps was rather sketchy. As a professional PHP developer I did not find anything useful in this sample. Everything was obvious, tests were only briefly mentioned without telling how you are supposed to get the code under test in the first place.
That’s different in the Michael Feathers’ book, because he shows in detail how to get your code under test in order to enable the required change.
Refactoring a large legacy application without a safety net of automated tests is a very scary undertaking. Paraphrasing Michael Feathers, there are two ways to change code: the industry standard edit and pray and cover and modify. Paul M. Jones does not describe (at least in the sampled chapters) how to cover, only how to modify. This amounts to the edit and pray methodology.
The sampled chapters also lack discussion of how to handle the “black voodoo” so prevalent in many legacy code bases. It is not very difficult to find and eliminate all
include statements where the included file is explicitly specified, e.g.
But in many old and very large legacy apps the paths get calculated based on some voodoo logic and input that your get from user, e.g. read from
includes are the ones that make the refactoring difficult. They make it almost impossible to write tests, because old apps tend to have little to no documentation. You cannot test everything after every change, because nobody knows every little feature that exists in the app, not even QA team. And not everything is covered by tests. But your customers still use those features. So, what to do in this case?
This is a very common problem in old software. Unfortunately it doesn’t get addressed at all.
Having said that, I am still curious whether other chapters discuss these issues.
Don’t judge a book by its [sample chapters].
But yeah, the chapters do discuss testing into more depth, both characterization tests of the legacy mess and the more fine tuned tests of the newly refactored / built components. Though you are right - dynamic includes are a very important part that shouldn’t be left out.
I try not to.
I ordered a copy now. Let’s see whether it is as good as the reviews claim.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.