Working Effectively with Legacy Code
I haven't publish any book review for a while. It does not mean I am not reading books anymore. I just didn't feel that some of the books I read recently require my recommendation, or I didn't have any thoughts that I needed necessary to share right now.
I have added a few books to my favorite books list though. Check them out!
Working Effectively with Legacy Code deserves a blog post because of a few reasons:
- Every Software Developer should read it
- It's not really about legacy code
- Published in 2004 (12 years ago!) is still very up to date
The book has three parts:
- Importance of unit tests when changing software
- Recipes for real world problems that we face when changing software (e.g., "I need to change a monster method" or "What methods should I test when introducing a change")
- Dependency-breaking techniques catalog
The first part should be familiar to most programmers these days. If it is not for you then you should read Agile Principles, Patterns and Practices (by Robert Martin), TDD by Example (by Kent Beck), and The Art of Unit Testing (by Roy Osherove). You can thank me later.
The second part is the essence of the book. It shows, by example, how to add a new feature, make a change to existing code, or fix a bug. Most books about software development, present examples of very simple, clean code that we never see in the real World. This book takes some messy pieces of code and shows how to make it testable, how to get rid of too many side effects and clean it up by separating dependencies and responsibilities. Many times we want to test one functionality, and then we realize that we need to instantiate tens of objects that another method depends on. Sounds familiar? This chapter shows how to handle that.
The last part (Dependency-Breaking Techniques) is very similar to Martin Fowler's Refactoring: Improving the Design of Existing Code. It's a set of techniques and a step-by-step description of how to apply them to existing code.
As I mentioned earlier. This book is not really about legacy code. I think it is more about evolving existing code. It is natural, when adding features, we add lines of code to the method. The hard part is to know when you should extract a new method or introduce a class and refactor dependencies. It's OK to have global variables. The problem is to keep track of them or localize them. How do you know, that adding new functionality will not break something? Do you have 100% test coverage for every possible use case? That's not possible because of the complexity of the software we are creating today. "What methods should I test" shows a neat technique to backtrack effects and side effects of a change that we are introducing.
There is much more, and you should check out this book. You don't have to read it from cover to cover. I strongly recommend you, at least, to scan through part 2 (changing software), and I am sure you will learn something new that you can apply to your project today!