Page 163 -

Refactoring makes intuitive sense, when one considers the main reasons that code
becomes difficult to maintain. As a project moves forward and changes, code that was
written for one purpose is often extended and altered. A block of code may look pristine
when it’s first built, but it can evolve over time into a mess. New functionality or bug fixes
can turn clear, sensible code into a mess of enormously long and complex loops, blocks,
cases, and patches. Some people call this spaghetti code (a name that should make intui-
tive sense to anyone who has had to maintain a mess like that), but it is really just code
whose design turned out not to be all that well suited to its purpose.
The goal of refactoring is to make the software easier for a human to understand, without
changing what it does. Most modern programming languages are very expressive, mean-
ing that any one behavior can be coded in many different ways. When a programmer
builds the code, he makes many choices, some of which make the code much easier or
harder to understand. Each refactoring is aimed at correcting a common pattern that
makes the code harder to read. Code that is easier to understand is easier to maintain, and
code that is harder to understand is harder to maintain.

In practice, maintenance tasks on spaghetti code are extraordinarily difficult and time-
consuming. Refactoring that code can make each of these maintenance tasks much easier.
Well-designed code is much easier to work on than poorly designed code, and refactoring
improves the design of the software while it is being built. Any programmer who has to
maintain spaghetti code should make extensive use of refactoring. It usually takes about as
much time to refactor a block of spaghetti code as it does to simply try to trace through it.
In fact, many programmers have found that it’s much faster to use refactoring to perma-
nently detangle messy code than it is to try to just fix the one problem that popped up at
the time
In addition to saving time on programming, refactoring can also help a programmer find
bugs more quickly. Poorly designed code tends to have more defects, and tracking these
defects down is an unpleasant task. If the code is easier to read and follow, it is easier to
find those bugs. And since much of the duplicated code has been eliminated, most bugs
only have to be fixed once. Of course, the clearer the code is, the less likely it is that
defects get injected in the first place.

There is no hard-and-fast rule about when to refactor. Many programmers find that it’s
effective to alternate between adding new behavior and refactoring the new code that was
just added. Any time a reasonably large chunk of new code has been added, the program-
mer should take the time to go through it and find any possible refactorings. The same goes
for bug fixes—often, a bug is easier to fix after the code that it’s in has been refactored.

NOTE
Additional information on refactoring can be found in Refactoring:
Improving the Design of Existing Code by Martin Fowler (Addison Wesley,
1999) and on his web site at http://www.refactoring.com.

DESIGN AND PROGRAMMING 155