Book Review: Working Effectively With Legacy Code by Michael Feathers
When you think of “legacy code”, what do you think of? For a lot of developers, they think of Cobol, RPG, or some other “ancient” language. For Michael Feathers, legacy code is code that does not have tests. Plain and simple. That java class you wrote yesterday for a quick hack without any tests? That was legacy code the minute you wrote it. His book, Working Effectively with Legacy Code, covers all sorts of techniques to bring legacy code under test, using procedural and OO languages.
Feathers follows a format similar to a FAQ, with “chapters” that have titles like I’m Changing the Same Code All Over the Place, and I Can’t get this class into a Test Harness. The format makes the book much more friendly as a desk reference then a start to end read, though I decided to just dive in and read it straight through. Some chapters look very similar to the listings in Fowler’s Refactoring, while others are a bit more high level when the topic doesn’t follow a standard step by step process. This book is very much a low-level “deep in the code” type book, with code examples from languages as varied as C and C++ to Java and a little Ruby. Definitely not for the novice developer who is just starting out with TDD.
For the intermediate to advanced developer, however, this book is a gold mine. Feathers covers dependency breaking techniques to bring tightly coupled classes under test, and also covers many methods for introducing sensing objects to detect changes through your tests. I found the sections on doing automated refactorings without tests to allow tests and further refactoring particularly helpful, as was the chapter on dependency breaking refactorings. Some of the C/C++ chapters were a bit difficult to get through, as I haven’t done any work in C++ in six or seven years and don’t plan on doing any in the future. I still pushed through to see some of the challenges (and opportunities) that come with the older languages out there.
This is a great book for the test driven developer, even those who maintain the discipline in writing tests firsts. Inevitably you will have to change a coworkers code that is not under test, and this reference should be at your side when you do it.