Refactoring: Doing design after the program runs

If you have worked with objects for any length of time, you have heard about iterative development. The idea of iteration is that you cannot get a design right first time, but refine it as you build the software. By iterating over the design several times you get a better design. Even throwing away code helps, as it is the sign of a good project. To not do so indicates a lack of learning, of keeping bad ideas.

Refactoring is the controlled process of altering the code so its design is what you want now, rather than what you wanted then.

Iteration is great to discuss, but it has some problems in practice. If you make a change to existing code does that carry the risk of introducing bugs? While people have come up with various methods for design in advance, there is little about applying them in an iterative process, or doing the iteration in a controlled and efficient manner.

Refactoring is the first technique I`ve found that is explicitly about doing controlled iterative development. It starts with working software, which is not well suited to enhancement. Refactoring is the controlled process of altering the code so its design is what you want now, rather than what you wanted then. A series of code transformations, or refactorings are applied.

Each refactoring changes the code rapidly, without introducing bugs. Essentially there are two routes. The first is with manual techniques; the second relies on tools. Although using tools is less common, I`ll start with that.

Semantics-preserving or transformation that you can prove will not change program execution, is the essence of this approach. An example of this is the Extract Method. A long section of procedural code can be made easier to read by taking a suitable chunk of the code and turning it into a separate method. With a tool you select the code you wish to extract, it analyses the code, identifying temporary variables and parameters that need to be passed between the extracted method and the program. The tool then prompts for the new method and parameter names and creates the new method with a call from the old program. The program works exactly the same as it did before, but is easier for a human to read. This is important: any fool can write code that a computer can understand, the trick is to write code that humans understand.

The tool builder has to prove that the refactoring is semantics-preserving and figure out how to prove the validity of the transformation in the code. It`s hairy stuff and requires compiler technology knowledge, but it can be done. The benefit is immediate, after encoding, you can use it with confidence. And it never adds bugs.

Tools like this are not science fiction. Bill Opdyke of the University of Illinois proved several of these refactorings. Two other graduate students, John Brant and Don Roberts, have produced a Refactoring Browser for Smalltalk. Smalltalkers should download it from http://st-www.cs.uiuc.edu/users/droberts/Refactory.html. The refactoring browser is an awesome tool. Is refactoring still applicable when working outside of Smalltalk? Yes, but not with tool support.

Manual refactoring is not as easy but still possible. It boils down to two principles: take small steps and test frequently. Humans can use the same semantics-preserving transformation as the tools.

You look for the local variables yourself. It takes a little longer, but it isn`t too difficult as you are looking at a small section of code. Then move the extracted code, put in the call and recompile. Done correctly you won`t get any bugs. You need to have a battery of tests that exercise the code, sufficient to exclude new bugs. If you build self-testing code, then you already have those tests. If not, then build them. Tests are useful since they make it easier to add new function as well as refactor.

When you follow a rhythm of small change, test, small change, test; you can make some remarkably large changes. I`ve gone into pretty nasty code, and after a few hours found class structures that radically improve the software design, without having the design in mind when I start. I refactor initially to understand the code, then I begin to see a better design and alter the code accordingly.

Refactoring to understand code is important. This is true when working with someone else`s code, and also of your own code. Commenting provides similar understanding, but it`s better to refactor so the intention is clear from the code, then it does not need many comments. Some refactorers claim that most comments are rendered unnecessary. I don`t go that far, but I do prefer to reach clarity through good factoring.

Refactoring has become a central part of my development process, and of the process I teach. It`s a design technique that complements the up-front design techniques advocated by the UML and others. Its great strength is that it works on existing software. I often work with an existing code base. Refactoring allows manipulation and improvement without creating bugs. With new code it gives developers the ability to change designs with a much better controlled iterative development process. Development speed improves significantly. When adding new functionality, it is quicker to first refactor the existing software to make the change easier. Don`t set aside time for refactoring, rather do it because you need to add a feature or fix a bug. This makes it easier to justify to sceptical managers.

The biggest problem with refactoring is where to find out more. I`m currently writing about it. You can find more information about refactoring at http://ourworld.compuserve.com/homepages/Martin_Fowler/.

I hope I`ve stimulated you to find out more. I believe refactoring is one of the crucial new developments. Tools that include refactorings will be very important to software developers. I`m interested to know what you think; drop me a note at fowler@acm.org.

• ObjectActive 99 is sponsored by Software Futures and Sun Microsystems. It will be held in Johannesburg at the VW Conference Centre from 22 to 24 June and in the Cape at Table Bay Hotel from 29 June to 1 July. For further information, contact Derek Hughes on (011) 807-1340 or derekh@softwarefutures.com or visit the Web site at www.objectactive.co.za.