LegacyCode_blog I’m only a little behind in reading for my 2010 developer-oriented book reading list, but I seem to be falling quite a bit behind in actually writing up book reviews. Here’s a belated review from my May book, Working Effectively With Legacy Code by Michael Feathers.

I chose this book because I had heard people rave about it years, so I went in with pretty high expectations.

Although I wasn’t quite as smitten by the book as I had hoped, I did find enough value in it to give a presentation based on the concepts and strategies featured in it at the Kansas City Developer’s Conference a few months ago. You can download my slides and sample code here.

Rating - star_sm star_smstar_sm (out of 5)

Prerequisites

  1. You’re interested in TDD (or even just unit testing) – It’s important to note that the author defines legacy code as any code that doesn’t already have tests covering it and that all the strategies presented in the book are aimed at helping you make code more testable. You definitely don’t need much experience or expertise in TDD to benefit from the book, but if you’re philosophically opposed to TDD then this isn’t the book for you.
  2. You’re comfortable with multiple languages – Examples in this book are in C#, C, C++, Java, and Ruby. If you’re not comfortable looking at samples in these languages or it feels like a waste of time deciphering code that you don’t use in your day to day work environment, then you’ll be frustrated with this book.
  3. You understand and use an object oriented language – Although Michael Feathers covers a few non-OO techniques, such as linking and preprocessing based test seams, the vast majority of the techniques rely upon object oriented language features such as inheritance and interfaces. If you spend all of your time working with a procedural language, I would recommend just reading the few relevant pages in the book store rather than investing much time and money in this book.

The Good

  1. Conceptual Scaffolding – The author introduces a few incredibly helpful concepts, test seams and enabling points, which serve as scaffolding for the entire book. This scaffolding technique is incredibly effective in helping readers digest and remember the material and the author deserves high praise for having done this so well.
  2. Pragmatic Approach – Anyone who spends much time maintaining a legacy system has a healthy disdain for unfettered idealism. Michael provides a helpful and realistic assortment of techniques that allow you to iterate a design in a safe and timely manner. He freely admits that a few of his techniques should only be used as an intermediate step to help facilitate getting some initial tests in place, but that doesn’t make them any less useful.
  3. The Power of Naming – Many of the techniques described in the book were familiar to me because I had naturally stumbled upon them myself while trying to put the code I work with everyday under test. Just like with the Gang of Four’s Design Pattern book or Martin Fowler’s Refactoring book, the real value of this book is not in how innovative it is but rather in how meticulous it catalogs and names existing patterns, thus providing a common language for developers to more effectively collaborate on design issues related to testability.

The Bad

  1. Not Very Original in Places – Several chapters in the middle of the book seemed like generic repeats of some of Bob Martin’s SOLID material or Martin Fowler’s Refactoring techniques. If you’ve read those books before, then you’re bound to be a little disappointed like I was when you reach those parts of the book. 

Mixed Feelings

  1. No Use of Mocking Frameworks – Part of me really appreciates the fact that the author did not use any mocking frameworks in the book. Before reading the book, mocking frameworks seemed like magic to me, but now I feel like I have a pretty good idea of how I would implement one from scratch (if I ever wanted to) because I now clearly understand all the different ways to substitute functionality dynamically. It’s actually very simple stuff, I just never took the time to think about it before. On the other hand, not covering the use of a mocking framework in the book also means that someone new to unit testing is going to be ill-equipped to productively enter the world of TDD, where mocking frameworks are pretty much a given these days.

Conclusion – . Despite being slightly disappointed by the book due to some extremely high expectations I still think that this book fills an important knowledge void (how to make legacy code testable) and thus belongs on any developer’s top 10 must-read list.

Popularity: 1% [?]