Michael Feathers

We wise programmers know that code should be written to minimize dependencies, inject those that are necessary, use interfaces, be tested from the start, etc. etc., and we always write our new code like that (right?), but our good habits and wisdom don’t matter when working with legacy code. You don’t have the option of going back in time and smacking some sense into the original author (who may have been your younger, more foolish self).

Given that we have to deal with legacy code, how can it be made easier? The fundamental premise of Working Effectively With Legacy Code is that you cannot work effectively with code unless it is covered by tests. When working with untested code you must be extremely careful, and even then the results are uncertain.

As a result, the bulk of this book is dedicated to techniques for helping get legacy code under test (specifically, fast running unit tests). Many of the techniques used for working with legacy code are well known testing or refactoring patterns, but Feathers puts them in a new light which highlights some of the special difficulties of working with legacy code.

Unlike code that was written with tests in mind, legacy code can be notoriously hard to test. The main enemy of getting tests in place is complex dependencies. To test a piece of code, you may have to create many other configuration objects, and some of those may be impossible/expensive to create in tests (e.g., live network connections). Even worse, you may not even have the hooks to create those objects because they are created deep within the code.

This brings up what Feathers calls “The Legacy Code Dilemma”:
When we change code, we should have tests in place. To put tests in place, we often have to change code.

To get around this dilemma, Feathers introduces the reader to low risk ways to introduce tests into existing code. Because these changes still have some risk, he recommends only adding tests to code you are working on. Don’t just go and start introducing tests everywhere because that requires changing code and may introduce bugs.

Feathers presents a catalog of techniques for introducing tests and breaking dependencies. I won’t go into them in detail (there are a lot). I will note that I am not that fond of the format of the chapters. Feathers names each chapter as if it were a question in a FAQ and then uses the chapter to answer that question. This will probably be great when I am trying to do something and think, “Didn’t that book have something to say about that?”, but it feels kind of hokey when just reading it as a book.

There are some common themes throughout this book. Dependency breaking is one. Another is that sometimes you have to make code more ugly to get it under test. You may have to add partial interfaces or classes that exist only to break the dependencies. Feathers gives two pieces of advice to get over that: it’s better to have tested code than untested code, and often the ugliness is an intermediate stage in unearthing the deeper structure of the code.

This book is not all about testing, however. Feathers does spend some time talking about techniques for understanding legacy code and discovering where to change it. In fact, those were some of my favorite chapters since I find getting started on understanding complex code bases to be rather intimidating. Chapters 11, 12, 16, and 17 discuss techniques for understanding code. Feathers talks about different ways of increasing understanding including sketching effects, taking notes about code, scratch refactoring, and telling the story of the system. I have found the effect sketching to be particularly useful in my day-to-day work.

Overall, this was a valuable read for anyone who has to understand and change large, confusing, delicate code bases (and what code base that has been around awhile isn’t?). The structure of the book made it repetitive at times, but the value of the contents outweighed the occasional repetition.… (altro)