Claudio Lassala's Blog

Yesterday I’ve finally finished reading the following book:

Working Effectively with Legacy Code (Robert C. Martin Series) by Michael Feathers Read more about this title…

I had already heard great comments about it, and then over a month ago my buddy Lynn Evans told me I had to read it and let me borrow his copy. I’m glad I did.

I must say when I first saw the title of this book, I thought to myself: "hmm… it’s probably all about old C code, mainframe applications, etc. I don’t think I’d be interested in this book…". Boy, was I wrong…

Yes, there’s quite a bunch of sample code in languages I’m not particularly comfortable with, such as C++, Java, and C, but anybody used to C# or VB should be able to follow the examples without a problem (not that I wouldn’t like to see a C#-only version of this book, but that’s beyond the point…).

Even though some people, like myself, would read the "legacy" in the title and think that wouldn’t apply to code written as back as this morning, the author quickly explains what legacy code is: any code without test is legacy code.

According to the author, it doesn’t matter how badass the design and implementation of some code may be, or how killer the developer who wrote is; if there’s no tests for the code, it’s considered legacy code.

When I think of legacy code, I think of code that’s hard to maintain. It’s hard because I don’t know what impact any change I make to the code would have on the application. Since there are not tests, even a one-liner change can be dangerous; let alone some more major changes.

Even before the first chapter starts, I’ve already run across this gem:

Designs that cannot tolerate changing requirements are poor designs to begin with. It is the goal of every competent software developer to create designs that tolerate change.

The book covers many techniques for writing tests for code that hasn’t been written with tests in mind. It tackles typical questions such as "how do I test private methos? And should I?". It also presents considerations on removing dependencies so to be able to put the code under test, as we do that, we usually end up with code that’s easier to maintain and extend. All of this going through lots of refactoring techniques.

I’m glad to see that quite a few of the techniques I’ve figured out on my own are listed in this book, with samples that come from real world experiences.

Excellent book, recommended to any serious developer.