Working effectively with legacy code

is an excellent book by Michael Feathers (isbn 0-13-117705-2). As usual I'm going to quote from a few pages:

A few years ago, I gave my friend Erik Meade a call after I'd finished work one night. I knew Erik had just started a consulting gig with a new team, so I asked him, "How are they doing?" He said, "They're writing legacy code, man."

To me, legacy code is simply code without tests. I've gotten some grief for this definition… I have no problem defining legacy code as code without tests. It is a good working definition, and it points to a solution.

In nearly every legacy system, what the system does is more important than what it is supposed to do… Frankly, it's very important to have that knowledge of what the system actually does someplace.

When teams aren't aware of their architecture, it tends to degrade. What gets in the way of this awareness? … The brutal truth is that architecture is too important to be left exclusively to a few people.

When you have tests around the areas in which you are going to make changes, they act as a software vise [vice]. You can keep most of the behaviour fixed and know that you are changing only what you intended to.

The most subtle bugs that we can inject are bugs related to inheritance. … The language feature that gives us the most possibility for error when we lean is inheritance.

Orthogonality is a fancy word for independence… One of the startling things that you discover when you start removing duplication zealously is that designs emerge.

Sometimes it makes sense to add a variable to a class and use it to sense conditions in the method that we want to refactor.

…not all behaviours are equal in an application.

Code is pretty fragile material.

At this point in my career, I think I'm a much better programmer than I used to be, even though I know less about the details of each language I work in.

The primary purpose of a compiler is to translate source code into some other form, but in statically typed languages, you can do much more with a compiler.