Refactoring is the practice of improving the design of a system without changing its behavior. Refactoring is a
critical practice and skill in iterative development. The programmer is either adding a new feature or refactoring. XP
programmers consciously choose between refactoring and adding new functionality on a minute-by-minute basis. Some
refactorings are trivial, such as renaming or moving things. Other refactorings allow you to exchange procedural logic
with polymorphism, and still larger refactorings exist to introduce design patterns.
While processes like Extreme Programming rely on refactoring to let the design emerge, the usefulness of refactoring
extends beyond the Agile Methodologies. As feature requests and bug fixes require changes to a system, refactoring
techniques allow the programmers to maintain a good design. Refactoring can also be used to improve the design of an
Refactoring is not new. Developers have been refactoring for years, though only recently have people started to catalog
refactorings. Refactoring has become such an important part of development that professional-level Integrated
Development Environments (IDEs) either include built-in tools or have plug-ins to provide refactoring support.
If your system isn't being refactored as it is modified, your design deteriorates; methods become longer, classes take
on more responsibility, more code gets cut and pasted around your system, previously cut-and-pasted code has to be
modified in several places.
If your system becomes brittle and inflexible, your developers will have to spend more time and money to add features
or fix bugs. As the design continues to deteriorate, fixing one bug creates two more, or the cost of adding a new
feature out weighs the benefit of having it because so much of the system has to be modified. There are many analogies
to describe this battle against entropy; from cleaning as you go to design debt.
Knowing the refactorings isn't enough. Developers must be able to identify problem areas of the program design (often
referred to as "smells"). These are the places where refactoring can be used to improve the design of the code. Design
skill and experience are needed to recognize bad code smells.
Automated tests provide a safety net when making changes. The automated tests report when the functionality of the
system changes. Make a structural change to the software; see that the tests still pass. You can confidently refactor.
Where do all these tests come from? In XP, they are developed using Test-Driven Development. It is possible to refactor without tests, but you run the
risk of unknowingly introducing bugs or breaking existing functionality.
Allows the design to emerge over time.
Keeps the design from rotting.
Reduces cost of change.
See the Refactoring Guidelines.