The Importance of Refactoring in eXtreme Programming

Why refactoring?

Achilles
But the whole system isn't small, you may be coding little bits at a time, but you've still got to design the whole system first.

Tortoise
No, actually you don't. In fact, judging by the amount of mistakes people make, it appears to be impossible to do a good job of designing a system before it's built.

Achilles
But you can't design a system after it's built.

Tortoise
No, but you can design one, whilst it is being built!
From Misconceptions in XP II

Refactoring is vital to the success of the entire XP methodology. In the quote above, the Tortoise asserts that you can design a system while building it at the same time. One common objection to the XP process is that it is unstructured:

Coding begins very early in the process
early code is written to be as simple as possible
large but scalable designs are discouraged in favor of using the best, simplest tool/structure/algorithm for the job at hand

These attributes seem to be advocating sitting down and hacking out the code as soon as possible rather than creating an elegant, scalable, modular system. Indeed, these steps may often produce hackish code; therein lies the importance of refactoring. From Misconceptions in XP II: "Refactoring erases the smelly wounds that new code inflicts on a system."

Refactoring allows a rapid development process and simple code structure while maintaining clean, scalable, and modular code.

The importance of refactoring

Without rapid, early coding, projects can spend many months in the design phase only to be discovered to be impractical, overbudget, or overschedule once coding starts. Without refactoring, a project can devolve into unusable, unmaintainable spaghetti code.

Refactoring also slightly delays the coding of important infrastructure. As stated above, the program is designed as it is written, not before. Important design and infrastructure details are laid out as necessary, not at the beginning of a project before the programmer/designer does not have the necessary information to make an informed decision.

What is involved?

There is no "canonical form" for code after which point refactoring is completely unnecessary. Code is refactored until it satisfies the teams notions of good XP code. There is often no end to refactoring, it is a process rather than a goal; one can never say "Function X is done being refactored." Refactoring is an art and thus requires some experience, but since many members of a team have the opportunity to refactor a piece of code, their collective experience often produces far better infrastructure than a "master planned" infrastructure designed by a smaller design team would.

Characteristics to strive for in refactoring include:

Clarity: the meaning of the code should be obvious to anyone reading it. Comments can be refactored as well for adding additional explaination for hairy code, but one should try to make the code itself clear enough to understand
Eliminate redundant code: refactoring is the time to recognize patterns and factor them out of your code. Similar and redundant classes and code blocks should be combined, and unnecessary functions and variables eliminated.
Modularity and Scalability: code should be easy to extend or modify, and be able to scale without adding complexity
Simplicity: if the code was written using the XP process, it should already be almost as simple as possible...complexity should not be added unless absolutely necessary to improve readability or modularity.

Even though refactoring is often performed throughout software development, its purpose it to effect a more major change. Refactoring is not bug fixing or what most people would think of as incremental improvements. It is a series of small (sometimes larger) redesigns to code. Refactoring brings out patterns and redundancies in the code without having to start with a pattern in mind or having to understand the whole system at once and deduce the patterns on your own.

Also, refactoring has nothing to do with adding more features. It is used on already sucessfully executing code and most often does not affect the function of that code, but only its structure.

Implementation issues

If refactoring is so great, why doesn't everyone do it?

Refactoring means having to go back over one's own code. Especially when deadlines loom, working code is often assumed to be good-enough code. Refactoring can become another post-process like internal documentation that everyone recommends but that few programmers actually have the time to perform. As Cooper puts it in Extreme Programmming vs. Interaction Design, "There's enormous cost in writing code, but the real cost in writing code is that code never dies. If you can think this stuff through before you start pouring the concrete of code, you get significantly better results."

This can be addressed through several means. If code is kept simple, then going back over and having to understand everything again is significantly easier and the programmer is more likely to do it.

Also, XP advocates a principle known as Collective Code Ownership where everyone is responsible for the quality of the code as a whole, and has the ability to change any part of it. Thus, other programmers may refactor code if it was not abstracted to their satisfaction before; that is, if the code is too ugly (or smelly, in XP terminology), it will be noticed and fixed by the next person to work with it even if the original writer neglected this. Peer pressure can ensure that people don't neglect refactoring in the first place.

Refactoring, since it only changes code structure and does not introduce new functionality, is sometimes so mechanical that it can be performed by a software tool, see the "Refactoring Tools" section of the Refactoring Home Page for more information on this.

References:

Extreme Programming article at Object Orientation Tips:
http://ootips.org/xp.html

Extreme Programming FAQ:
http://www.jera.com/techinfo/xpfaq.html

Misconceptions in XP II: Achilles and the Tortoise Discuss Design:
http://www.xprogramming.com/xpmag/AchillesTortoise.htm

Refactoring Home Page:
http://www.refactoring.com/

"Refactor Mercilessly" from The Extreme Programming home page:
http://www.extremeprogramming.org/rules/refactor.html

Several Wiki entries:
Refactor Mercilessly
http://c2.com/cgi/wiki?RefactorMercilessly
Refactor Improving The Design Of Existing Code
http://c2.com/cgi/wiki?RefactoringImprovingTheDesignOfExistingCode
Re Factor
http://c2.com/cgi/wiki?ReFactor
Refactoring Equals Reparameterization
http://c2.com/cgi/wiki?RefactoringEqualsReparametrization
What Is Refactoring
http://c2.com/cgi/wiki?WhatIsRefactoring

Last modified 1/23/02 by Jacob Mundt