Book Review: Working Effectively With Legacy Code
Every Software Developer should read it; it’s not really about legacy code.
Join the DZone community and get the full member experience.Join For Free
Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.
I haven’t publish any book reviews lately. It does not mean I am not reading books anymore. I just didn’t feel that some of the books I read recently requires 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 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 on very simple, clean code that we never see in the real world. This book takes some messy piece 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 other 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 step by step description 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 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 a new functionality will not break something? You have 100% test coverage for every possible use case? That’s not possible because of complexity of 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 scan through part 2 (changing software), and I am sure you will learn something new that you can apply to your project today!
Published at DZone with permission of Jakub Jedryszek, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.