Working Effectively with Legacy Code

The book was written by Michael Feathers, and was published in paperback format in 2004. Some searching on the web shows that the book is consistently well recommended by programmers.

The purpose of the book is to provide guidelines on refactoring a code base to enable testability. Michael points out that the process will not happen with one refactoring; rather, it will take multiple, even many, incremental changes to bring the code in line.

The book is divided into three parts. The first is a multi-chapter introduction, covering the need for change, the roadblocks in the way, and the tools involved in the process. The second section is the meat of the book, with eighteen chapters on the different ways to refactor code to enable testing. The final section contains a listing of the different techniques previously discussed, along with information on why you would use each technique and the steps involved.

I like the naming of the chapters in the second portion of the book. There are titles such as “I Can’t Get This Class into a Test Harness”, “This Class Is Too Big and I Don’t Want It to Get Any Bigger”, and “I’m Changing the Same Code All Over the Place”. The titles are very useful, since just by looking at the table of contents, you can quickly determine which chapter you need to turn to for your current task.

One statement early in the book really stood out for me, as follows…

Legacy code is code without tests.

I like that. I think that is a clear way to describe the nature of legacy code, being that unit tests are such a good practice and no good code should be without them.

One interesting thing that gets pointed out is that it is preferred to have tests in place before ding refactoring, and yet refactoring may be needed to get those same tests in place. It is an interesting paradox, one that Michael resolves by demonstrating the use of smaller, less invasive changes, ones that are less likely to cause problems. Then tests can be added, then more serious refactorings can happen.

The book presents example code in C, C++, and Java; the switching between languages so regularly can be a little disconcerting to the reader, but the samples do serve to make the concepts and techniques clear. The fact that code is only shown in those three languages is not important – it is the concepts that the book is trying to emphasize, and those can be equally applied to any common programming language. Because of that, this book won’t be outdated any time soon, as the material is timeless.

All in all, the book was a bit of a read, but it is absolutely worth the time. The information gained can only help to improve sub-optimal code, and to prevent new code from being that way in the first place. I think this material is so useful that I will be keeping the book handy when working on some of my older projects. This book is timeless, and I highly recommend it.