Working Effectively with Legacy Code
by Michael C. Feathers

ISBN: 0131177052
Publisher: Prentice Hall PTR
Pages: 456

This is an important book. Not at least for the ones of us making a living by developing software: the ideas in this book may prove to be the difference between a smooth, predictable change to existing code, contra countless hours of overtime and frustration over unpredictable software behavior.

Michael Feathers definition of legacy code is simply code without tests. I find such a definition useful to categorize a software module; with unit-tests the quality is probably rather high and the software easy to maintain. The reason is that in order to write good unit-tests, a developer has to focus on keeping dependencies loose. On the other hand, with legacy code there are no unit-tests and this implies that the developer was not forced to care and control the dependencies. The resulting software is likely to have stronger dependencies than the one under unit-tests, making the module harder to extend and maintain.

The theme of dependency control recurs throughout the book. In many code bases it is simply not possible to get the code under test due to strong, complicated dependencies. Michael Feathers makes it clear that in order to get legacy code under test those dependencies have to be broken. This introduces a catch-22: I need unit-tests in order to make safe changes, but I cannot add unit-tests without actually changing the code. This problem is addressed by the included catalog of dependency-breaking techniques, safe to perform initially without test coverage. The catalog is accompanied by motivating and enlightening discussions illustrated with lots of code in different languages (C, C++, Java, etc).

The book also introduces simple diagrams used to reason about and understand the behavior and dependencies in the code. The notations are easy to understand and I will definitively give the techniques a chance.

I found the book easy to read. Michael Feathers writes in a very practical and entertaining way. The only negative criticism I have, is that the text may feel repetitive at some points. Anyway, that is a cheap price to pay; at least it ensures that the importance of breaking dependencies and getting code under test stays in the mind of the reader.

Finally, I would like to point out that I believe the book will apply equally well to “green field” development, but in this case the usage is slightly different: ensure that the code never degrades to legacy status.

Reviewed June 2005