Several people have recommended this book to me over the years. I only recently got around to reading it. Software developers continue to recommend this 15-year-old book for good reason. It is quite useful because we all encounter legacy code and all of its techniques are still highly relevant.
The main thesis is: In order to work effectively with legacy code you need tests in place. Why? “It’s only a simple change.” How many times have you heard that? The problem is that making that one change is the easy part. That’s like 1% of the job. The other 99% that is implied is: “Don’t break any existing features”. That is difficult and that is why we need tests, so we can verify that we haven’t broken anything. However, getting tests in place in legacy code can be quite a challenge.
The main enemy is dependencies. The logic you need to test often depends on things that are difficult to test or instantiate or have unwanted side effects. A lot of the book is about how to break those dependencies and get access to the things that you need to test and avoiding unwanted side effects. The book also talks a lot about seams and how to replace dependencies at test time.
Michael divided the book into 3 sections. The first section outlines the big picture, things like Why refactoring is important, why tests are important, what are seams and how do we use them, and what tools are available. In the last part of the book, Michael covers several dependency-breaking refactorings. You can perform these refactorings relatively safely without tests. These are often the first tool you reach for in order to get the code into a state where you can then write tests. The biggest chunk of the book is the middle third. It’s written in a FAQ style. If you have this particular problem here are some specific tools and techniques to help you out.
Overall it is a very useful book and I highly recommend it.
If you have some legacy code that you need help taming, give us a call and we’d be glad to talk about how we can help.