Refactoring

Related Sites

Refactoring is the act of changing the structure of code without changing its behavior. That act is accomplished in a long series of very tiny steps; each one of which is nearly worthless in and of itself. This long series of nearly worthless changes adds up to a significant change of high value over time.

After each tiny step in the refactoring, tests are run that verify that the software is sill working properly. Thus, from one tiny step to the next we know we have not broken anything.

When we refactor, we never take large leaps. We never tear the code completely apart and then struggle to put it back together again. We never wind up in the situation where we are 80% done but don't have the time to put things back together and have to abandon the effort. Rather, by refactoring in tiny steps we can stop at any time, leaving the code better than when we started. We are always sure, at every phase of the refactoring, that the code continues to function properly.

The size of the tiny steps I'm talking about is on the order of one to five minutes worth of coding.

[...] merciless refactoring of existing code [...] greatly decreases the sort of chaos I've seen in "clean and simple" code. It's almost like an emergent property, and I can't quite explain what's going on. The code becomes more fluid. The chunks are smaller so they have less trouble moving them to where they ought to be.

[...]

Like design patterns, refactoring codifies wisdom. This wisdom is about what good code looks like. I've encountered most of the refactorings in my professional life, but that was over the course of many years. I envy programmers starting out today with this sort of wisdom at their fingertips. Established programmers like me didn't even realize this was something that needed codifying.

It is the absolutely relentless elimination of duplication that keeps code modular. When you "must" remove duplication, you are "forced" to produce abstractions: superclass/subclass relationships, strategy objects, observers, and so on.

It is the absolutely relentless insistence on code that communicates the programmers' ideas that keeps code understandable. By pushing to express your design ideas in the code, you sharpen those ideas (and reduce the need for non-code documentation).

[...]

It turns out that by concentrating on the language level problems, you can improve the overall design. Design mistakes turn out to show up in improper allocation of responsibility among objects ... in duplication of function or code ... in awkward interfaces .. to a very large degree. I've found it surprising how much design improvement can come from what seems like mere "rote" manipulation at the code level.

Martin Fowler, Refactoring Home Page

Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts,
Refactoring: Improving the Design of Existing Code

WikiWikiWeb discussions about refactoring: ReFactor, RefactorMercilessly

William Wake, A Complete Refactoring Example: Part 1, Part 2

ootips, Extreme Programming