The Refactoring Cycle

There's a basic pattern for refactoring:

Start with a working program.

While smells remain :

• Choose the worst smell.

• Select a refactoring that will address the smell.

• Apply the refactoring.

We try to select refactorings that improve the code in each trip through the cycle. Because none of the steps change the program's observable behavior, the program remains in a working state. Thus, the cycle improves code but retains behavior. The trickiest part of the whole process is identifying the smell, and that's why the bulk of this book emphasizes that topic.

Is this approach to refactoring guaranteed to get to the ideal design for a problem? Unfortunately, no, as there's no guarantee that you can reach a global maximum by looking at local properties. But it's easier to get design insights that transform a solution when the code is as clean as possible.

Refactoring is like crossing a stream. One way to cross a stream is to take a running leap and hope for the best. The refactoring way is to find stepping stones and to cross the stream by stepping on one stone at a time.

When you start refactoring, it's best to start with the easy stuff (for example, breaking up large routines or renaming things for clarity). You'll find that this lets you see and fix the remaining problems more easily.