Working Effectively with Legacy Code

Rating:
Summary: excellent reference and guide
Review: "Working Effectively with Legacy Code" is a very valuable resource. The author defines "legacy code" as "code without tests." It doesn't matter whether the code was written last week or ten years ago. There is more emphasis on old code that nobody understands, mainly because it is messier and harder to work with.

The examples in the book are mainly in C, C++ and Java, but there are a couple in C# and Ruby. While it is essential to know one of these languages, the author provides enough information to understand the others. When a technique only applies to a certain language, it is clearly indicated.

The author shows how different diagrams can help you learn how to understand code. In addition to UML, there are dependency and effect sketches. The author uses these to show how to think about understanding and refactoring. Other tools, such as refactoring browsers and mocks are explained.

Speaking of refactoring, there are "dependency breaking techniques" (aka refactorings) with step-by-step instructions (Martin Fowler style) throughout the book. There are also explanations of why patterns and design rules exist. Most importantly, there are lots and lots of cross-references and an excellent index.

Working with legacy code isn't fun, but this book helps make it as painless as possible. With the split emphasis between psychological/understanding/techniques and refactoring, this book is both a great read and an excellent reference.

Rating:
Summary: Don't maintain code without it!
Review: (Copy of a review found at http://www.masterprogrammer.info)

The Point

If you need to fix, maintain or extend code without tests, and you're trying to do it without having a copy of this book by your side, you might as well just jab yourself in the stomach with a knife. Michael Feathers does for legacy code what the Gang of Four did for design: establish a vocabulary to make it easier to understand and communicate about how to work with legacy code.

The Details

There are some books that we use as references when we teach courses or do some consulting. These are usually the fundamental texts that provide an appropriate foundation for the reader in a given topic area: Java programming, programmer testing, enterprise architecture, what have you. Even before the book had been released, we were recommending it in courses on Test-Driven Development. The reason is clear: true greenfield projects are few and far between. A team trying to adopt Test-Driven Development has enough to learn; we can't leave them to their devices to figure out what they're going to do starting Monday. "How do we deal with the 250,000 lines of untested code we still need to use?" A Master Programmer cannot leave a team like that hanging.

Enter Michael Feathers and his years of experience rescuing legacy codebases. He has distilled his secrets into a collection of fundamental techniques combined with a catalog of strategies and approaches. In many ways, WELC is like other "how to" books: it starts with setting the context for the techniques, describes them with examples, then adds a catalog of ways to break dependencies in the back. One of the things that differentiates this book is the chapter titles. They are whimsical and, as a result, effective. Some examples follow.

* It Takes Forever to Make a Change
* I Need to Make Many Changes in One Area
* My Application Has No Structure
* This Class Is Too Big and I Don't Want It to Get Any Bigger

We have struggled with maintaining existing code, and in the process have had many of the exact complaints that Michael has made into chapter titles. Each chapter is rich with useful examples in Java, C# and C++. You'd be surprised how many requests we get for courses teaching Test-Driven Development in C++, and they have plenty of legacy code to work around! Michael's conversational style gives you the feeling of having him along side while you work, and frankly, you can't get Michael for only USD 45 plus taxes, but the book is a bargain at twice the price.

Post Script

In order to add book reviews to this web site (masterprogrammer.info), we needed to add a feature to a small amount of legacy code in PHP. (We're still learning how to test-drive PHP-based web sites, so we've made the classic mistake of worrying about it later. See how easy it is?) We used techniques like Sprout Method to make safe changes to the code that generates our Self-Study bookshelf while adding the ability to link a book to our review. What more proof do you need? To purchase Michael's excellent book, go back to our Self-Study bookshelf and click on Working Effectively with Legacy Code.

Rating:
Summary: A book for coders in the real world
Review: As a software coach, Michael has had to figure out how to work with a great many, um, suboptimal code bases -- and here's his experience all nicely packaged up for the rest of us. There are some neat techniques, such as the diagrams he sketches to help him understand disorganised classes, and a good catalog of patterns for somehow coping with that Big Ball of Mud you've just inherited. As with the best patterns, they all look familiar, but now they have names and you have a very respectable book to help you justify actually doing something about your situation. He also covers C++, which very few of the Agile community are prepared to deal with. One minor quibble is that there are no references -- but maybe that's what Amazon is for nowadays.

Rating:
Summary: refactor and test
Review: Feathers confronts a depressingly familiar problem encountered by many programmers. How to maintain a system of legacy code? Where often there has been no rigorous attempt to test it. Even in a manual fashion. He shows ways to build a test harness to automatically test the code. Even if this does not perform an exhaustive test, it may still be far in advance of what you already have (nothing?) to validate the code. He writes assuming that you might never have met a disciplined testing approach. So unit testing is carefully explained and he builds from there.

Simple, useful patterns like Decorator are described. The book is not meant as a comprehensive exposition of patterns. But hopefully, you can see the general idea of patterns and its utility. Large portions of the book are essentially about refactoring legacy code into these patterns, if possible. And also about testing your changes in a systematic way. If you do the former, you should also do the latter.

The examples are mostly in C++ and Java. But that's neither here nor there, if you program in other languages like C# or C. The ideas from the examples carry over well.

Rating:
Summary: Patterns and Refactorings Applied
Review: I got a copy of this book based on the title; I often work with legacy code that is hard to change and hard to test. As I read the book, I discovered that it directly addressed some problems that I was encountering on a daily basis. This book shows you how to apply patterns and refactorings to the problem of untangling dependencies in legacy code and making it more testable. And testing is an essential step to enabling change.

If you every develop software for commercial applications that already have an existing code base (this would be pretty much every system), you should buy this book. This book is an excellent companion to any book you have on testing, refactoring or patterns as it shows you how to apply these techniques to real problems.

Rating:
Summary: a wealth of practical information and solutions
Review: Martin Fowler's book on Refactoring showed us how to improve the design of our code. We learned to make changes safely, by taking small, rote steps, and by ensuring that we ran our tests after each small change. But what if we're working on the typical ugly system with no tests? In Working Effectively With Legacy Code, Michael Feathers tackles the problem that most of us end up dealing with.

Feathers does an excellent job of articulating the problems and scenarios, using clear examples from C, C++, Java, and C#. Many of the code examples look a lot like real examples I come across all the time--they don't appear to be fabricated.

Working Effectively With Legacy Code contains a catalog that provides a wealth of solutions. The catalog shows how to resolve concerns like, "I'm changing the same code all over the place" and "how do I safely change procedural code?"

The book is highly entertaining and comes across as a conversation with a really sharp, really patient guru developer. Often, it's a chore to slog through code-heavy books. But Feathers manages to keep my attention with interesting stories, loads of examples, and well-written text.

I think that Working Effectively With Legacy Code is an important book. The vast majority of existing code presents the classic catch-22: you can't change it safely because it doesn't have tests, and you can't write tests without changing it to easily support testing. It's not an easy problem, and most people will give you high-level ideas for solving it. Feathers is the first person to dig deep and present a wealth of knowledge and insight on the problem, all in one place. I'll be pulling this book from my shelf for years to come.

Rating:
Summary: No more fairy-land
Review: The average book on Agile software development describes a fairyland of greenfield projects, with wall-to-wall tests that run after every few edits, and clean & simple source code.

The average software project, in our industry, was written under some aspect of code-and-fix, and without automated unit tests. And we can't just throw this code away; it represents a significant effort debugging and maintaining. It contains many latent requirements decisions. Just as Agile processes are incremental, Agile adoption must be incremental too. No more throwing away code just because it looked at us funny.

Mike begins his book with a very diplomatic definition of "Legacy". I'l skip ahead to the undiplomatic version: Legacy code is code without unit tests.

Before cleaning that code up, and before adding new features and removing bugs, such code must be de-legacified. It needs unit tests.

To add unit tests, you must change the code. To change the code, you need unit tests to show how safe your change was.

The core of the book is a cookbook of recipes to conduct various careful attacks. Each presents a particular problem, and a relatively safe way to migrate the code towards tests.

Code undergoing this migration will begin to experience the benefits of unit tests, and these benefits will incrementally make new tests easier to write. These efforts will make aspects of a legacy codebase easy to change.

It's an unfortunate commentary on the state of our programming industry how much we need this book.


Rating:
Summary: Simply supurb, a tour de force
Review: The vast majority of software texts are about greenfield development: creating a new application from nothing at all. But the vast majority of software work involves existing code: adding features, finding bugs, or refactoring code that someone else wrote. This book is a supurb first step in fixing that imbalance.

This is not a theoretical work. For example, Feathers does not present a grand ontology of legacy systems. Not is this book heavy on methodology. Instead Feathers describes techniques --- lots of techniques, roughly 50 --- for working with legacy code.

The techniques are organized by the problems they address. For example, one chapter is entitled "My Application Is All API Calls" and then presents two techniques for working with existing code that is full of calls to APIs.

Feathers comes from the XP school, and he adopts that school's premise that you can safely change code if (and only if) there are sufficient tests in place to tell you when your new change has introduced a bug. Many of the techniques in this book are about different ways of putting legacy code into test harnesses, and doing that safely without introducing bugs along the way.

He also introduces new concepts, or at least concepts I had never seen before. For example, a "characterization test" is a test that characterizes the actual behavior of the code, not what the code is supposed to do, but what it actually does. Why is that useful? First, it is an effective way of documenting what a system actually does, particularly if --- as with most legacy code --- there is no other documentation. And it can tell you when you have changed that existing behavior.

Feathers' style is easy to read. As you would expect there is lots of example code here, and it is folded naturally into the explanatory text. My only gripe with the book is with the examples: they are largely in Java, C++, or C. I would have liked some examples in older legacy-only languages, like COBOL.

But overall, this book is simply supurb, a tour de force of an important topic that has received little coverage before.

Rating:
Summary: Pragmatically Improving the Past, Present, and Future
Review: This is pragmatic guide to safely dealing with past expediencies, present challenges, and creating a better future in your programs. The catalog of techniques to break dependencies and add unit tests applies whether the legacy code is 10 years old or 10 minutes old. I found many gems I could use immediately in a 15-year old app of over 600K lines of C++.

The basic ideas and perspectives apply on multiple scales. (method, class, component, and system.) I'd bet that developers who acquire these skills to tease apart legacy code would have great odds of writing new code that doesn't quickly turn into legacy code. I'm humbled by the depth of Michael's insight and fluency with these important issues. While it would be ideal to get mentoring by Michael, in your particular code base, this book is a life perserver while waiting for the budget approval. It is a reference I will return to frequently for development, and design & code reviews.

Rating:
Summary: Refactoring to tests.
Review: What Refactoring was to design, Working Effectively with Legacy Code is to (developer) testing. If you "can't write tests" because of your design (or lack of) this book will show you how.