The number of refactorings that would be beneficial to any specific program is essentially infinite. Refactoring is subject to the same law of diminishing returns as other programming activities, and the 80/20 rule applies. Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit. Consider the following guidelines when deciding which refactorings are most important:
Refactor when you add a routine. When you add a routine, check whether related routines are well organized. If not, refactor them.
Refactor when you add a class. Adding a class often brings issues with existing code to the fore. Use this time as an opportunity to refactor other classes that are closely related to the class you're adding.
Refactor when you fix a defect. Use the understanding you gain from fixing a bug to improve other code that might be prone to similar defects.
Target error-prone modules. Some modules are more error-prone and brittle than others. Is there a section of code that you and everyone else on your team is afraid of? That's probably an error-prone module. Although most people's natural tendency is to avoid these challenging sections of code, targeting these sections for refactoring can be one of the more effective strategies (Jones 2000).
Cross-Reference
For more on error-prone code, see "Which Classes Contain the Most Errors?" in Typical Errors.
Target high-complexity modules. Another approach is to focus on modules that have the highest complexity ratings. (See "How to Measure Complexity" in Control Structures and Complexity for details on these metrics.) One classic study found that program quality improved dramatically when maintenance programmers focused their improvement efforts on the modules that had the highest complexity (Henry and Kafura 1984).
In a maintenance environment, improve the parts you touch. Code that is never modified doesn't need to be refactored. But when you do touch a section of code, be sure you leave it better than you found it.
Define an interface between clean code and ugly code, and then move code across the interface. The "real world" is often messier than you'd like. The messiness might come from complicated business rules, hardware interfaces, or software interfaces. A common problem with geriatric systems is poorly written production code that must remain operational at all times.
An effective strategy for rejuvenating geriatric production systems is to designate some code as being in the messy real world, some code as being in an idealized new world, and some code as being the interface between the two. Figure 24-2 illustrates this idea.
Figure 24-2. Your code doesn't have to be messy just because the real world is messy. Conceive your system as a combination of ideal code, interfaces from the ideal code to the messy real world, and the messy real world
As you work with the system, you can begin moving code across the "real world interface" into a more organized ideal world. When you begin working with a legacy system, the poorly written legacy code might make up nearly all the system. One policy that works well is that anytime you touch a section of messy code, you are required to bring it up to current coding standards, give it clear variable names, and so on—effectively moving it into the ideal world. Over time this can provide for a rapid improvement in a code base, as shown in Figure 24-3.
