24.5. Refactoring Strategies

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 Section 22.4.

Target high-complexity modules Another approach is to focus on modules that have the highest complexity ratings. (See "How to Measure Complexity" in Section 19.6 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.

Figure 24-3. One strategy for improving production code is to refactor poorly written legacy code as you touch it, so as to move it to the other side of the "interface to the messy real world."

cc2e.com/2457

Checklist: Refactoring Safely

• Is each change part of a systematic change strategy?

• Did you save the code you started with before beginning refactoring?

• Are you keeping each refactoring small?

• Are you doing refactorings one at a time?

• Have you made a list of steps you intend to take during your refactoring?

• Do you have a parking lot so that you can remember ideas that occur to you mid-refactoring?

• Have you retested after each refactoring?

• Have changes been reviewed if they are complicated or if they affect mission-critical code?

• Have you considered the riskiness of the specific refactoring and adjusted your approach accordingly?

• Does the change enhance the program's internal quality rather than degrade it?

• Have you avoided using refactoring as a cover for code and fix or as an excuse for not rewriting bad code?