The Art of Agile Development, 2nd Edition

Refactoring

AUDIENCE

Programmers

We improve the design of existing code.

Code rots. That’s what everyone says: entropy is inevitable, and chaos eventually turns your beautifully imagined, well-designed code into a big mess of spaghetti.

I used to think that, too, before I learned to refactor. Now I have a 10-year-old production codebase that’s better today than it was when I first created it. I’d hate to go back: every year, it’s so much better than it was the year before.

Refactoring makes this possible. It’s the process of changing the design of your code without changing its behavior. What it does stays the same, but how it does it changes. Despite popular misuse of the term, refactoring isn’t rewriting. Nor is it any arbitrary change. Refactoring is a careful, step-by-step approach to incrementally improving the design of your code.

Refactorings are also reversible: there’s no one right answer, so sometimes you’ll refactor in one direction, and sometimes you’ll refactor in the other. Just as you can change the expression “x²–1” to “(x+1)(x–1)” and back, you can change the design of your code—and when you can do that, you can keep entropy at bay.

How to Refactor

You can refactor at any time, but it’s safest when you have a good suite of tests. You’ll typically refactor during the “Refactor” step of the test-driven development loop. You’ll also refactor to make a change easier or to clean up code.

When you refactor, you’ll proceed in a series of very small transformations. ...