Working Effectively With Legacy Code

Many of us have tried to discover ways to prevent code from becoming legacy. We’ve written books on principles, patterns, and practices that can help programmers keep their systems clean. But Michael Feathers had an insight that many of the rest of us missed. Prevention is imperfect. Even the most disciplined development team, knowing the best principles, using the best patterns, and following the best practices will create messes from time to time. The rot still accumulates. It’s not enough to try to prevent the rot—you have to be able to reverse

Ref. 4BF0-A

That’s what this book is about. It’s about reversing the rot. It’s about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system. It’s about reversing entropy.

Ref. 3F29-B

What is legacy code? I’ve used the term without defining it. Let’s look at the strict definition: Legacy code is code that we’ve gotten from someone else. Maybe our company acquired code from another company; maybe people on the original team moved on to other projects. Legacy code is somebody else’s code. But in programmer-speak, the term means much more than that. The term legacy code has taken on more shades of meaning and more weight over time.

Ref. CFE2-C

What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don’t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts. That definition of legacy code has nothing to do with who wrote it. Code can degrade in many ways, and many of them have nothing to do with whether the code came from another team.

Ref. E470-D

To me, legacy code is simply code without tests. I’ve gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Ref. DA67-E

I’ve been talking about tests quite a bit so far, but this book is not about testing. This book is about being able to confidently make changes in any code base. In the following chapters, I describe techniques that you can use to understand code, get it under test, refactor it, and add features.

Ref. BF1C-F

Four Reasons to Change Software For simplicity’s sake, let’s look at four primary reasons to change software. 1. Adding a feature 2. Fixing a bug 3. Improving the design 4. Optimizing resource usage

Ref. 23D1-G

behavior and changing old behavior. Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us. In the company logo example, are we adding behavior? Yes. After the change, the system will display a logo on the right side of the page. Are we getting rid of any behavior? Yes, there won’t be a logo on the left side.

Ref. A007-H