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 isn’t rewriting.

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.

...to continue reading, buy the book!

In this Section

1. Refactoring
   1. How to Refactor
   2. Refactoring in Action
   3. Questions
   4. Prerequisites
   5. Indicators
   6. Alternatives and Experiments
   7. Further Reading