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.
require_once 'path/to/file.php';
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 $_REQUEST. These 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.