Working Effectively with Legacy Code

by Michael C. Feathers

Designs that cannot tolerate changing requirements are poor designs to begin with.

nearly every system ever produced suffers from slow, debilitating rot.

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 it.

reversing rot is not easy, and it’s not quick.

this book describes a set of disciplines, concepts, and attitudes that you will carry with you for the rest of your career and that will help you to turn systems that gradually degrade into systems that gradually improve.

There is a big difference between adding new 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.

Adding a method doesn’t change behavior unless the method is called somehow.

It seems nearly impossible to add behavior without changing it to some degree.

One of the main reasons why many programmers don’t attempt to improve design often is because it is relatively easy to lose behavior or create bad behavior in the process of doing it.

The act of improving design without changing its behavior is called refactoring.

write tests to make sure that existing behavior doesn’t change

The key thing about refactoring from a change point of view is that there aren’t supposed to be any functional changes when you refactor

Optimization is like refactoring, but when we do it, we have a different goal.

In optimization, the “something else” is some resource used by the program, usually time or memory.

In all four cases, we want to change some functionality, some behavior, but we want to preserve much more

We have to figure out how to preserve the rest of the behavior.

we often don’t know how much of that behavior is at risk when we make our changes.

The difference between good systems and bad ones is that, in the good ones, you feel pretty calm after you’ve done that learning, and you are confident in the change you are about to make. In poorly structured code, the move from figuring things out to making changes feels like jumping off a cliff to avoid a tiger. You hesitate and hesitate. “Am I ready to do it? Well, I guess I have to.”

Often they aren’t aware of how much fear they have until they learn better techniques and the fear starts to fade away.

Edit and Pray is pretty much the industry standard.

When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.

The idea behind it is that it is possible to work with a safety net when we change software.

When we have a good set of tests around a piece of code, we can make changes and find out very quickly whether the effects were good or bad.

Traditionally, tests are written and executed after development.

they act as a software vise.

regression testing has traditionally been seen as an application-level testing style.

The tests won’t catch everything,

After every little change that we make, we run that little suite of unit tests.

Unit testing is one of the most important components in legacy code work.

Testing in isolation is an important part of the definition of a unit test,

Here are qualities of good unit tests: 1. They run fast. 2. They help us localize problems.

A test is not a unit test if: 1. It talks to a database. 2. It communicates across a network. 3. It touches the file system. 4. You have to do special things to your environment (such as editing configuration files) to run it.

Tests that do these things aren’t bad. Often they are worth writing, and you generally will write them in unit test harnesses.

However, it is important to be able to separate them from true unit tests so that you can keep a set of tests that you can ...