Refactoring

Study Questions

1. When are you upset by your code? What do you do in such cases?

2. Your team leader asks you to improve your code readability. How would you react ?

3. In one of your team meetings, one of the teammates declares: What I care about in software development is that the code runs. As soon as my code passes all tests, I leave it and do not improve either its structure or its readability. How would you react?

It is clear that the development of software is based on an iterative process through which the code structure is improved and other factors that influence its readability and comprehension are incorporated. Different software development methods deal differently with refactoring. For example, eXtreme Programming (XP) (see Chapter 2) includes refactoring as one of its 12 practices.

According to Fowler [Fowler00], refactoring is the process of changing a software code in such a way that although the observable behavior of the code is not altered, its internal structure is improved. When programmers refactor their code is not altered they usually remove duplications, improve communication, improve program comprehension, and add simplicity and flexibility. Accordingly, Kent Beck (in [Fowler00]) explains that the value that refactoring adds to a running program is expressed in the qualities that enable the team to continue developing at speed.

Refactoring aims to improve program comprehension mainly by improving the code design. For example, some refactoring actions lead to the elimination of duplicated code, so the code says everything once and only once. Although it may sound counterintuitive, refactoring helps us program faster because it leads to the production of code that is easier to work with and has fewer bugs and no patches.

An illustrative example for refactoring should be a relatively big computer program. However, as it is beyond the scope of this chapter, we do not base our discussion about refactoring on an example but rather on connections that refactoring has with human aspects of software engineering. Illustrative examples of code refactoring can be found in Refactoring: Improving the Design of Existing Code [Fowler00].

Task  

Look at the Refactoring home page ( www.refactoring.com ) and learn the main refactoring actions presented on the Web site. Refactor a program you worked on recently.

The reflective practice perspective (presented in Chapter 10) invites you to reflect on what you have done. Here are some reflection questions that can guide any reflective process that follows a refactoring session:

• What refactoring actions did you do and why?

• Is the code more comprehensible now? In what sense is the code improved now? What development actions can be performed easily now that could not be carried out before?

• Why was this refactoring conducted ? In what ways might it help other developers to work with the code in the future?

• How did you know what to refactor? What bothered you in the code?

• Is there an essential difference between the two code designs (before and after the refactoring process)? If yes, what is it?

• Couldn t you write the refactored code when you wrote it in the first time?

Let us focus on the last question: Couldn t you write the refactored code when you wrote it in the first time? In many cases the answer to this question is no. In this sense, the development of computer programs is similar to the way architects and other designers develop their creations. That is, only after some work is done is it possible to examine the work from the outside and to observe whether it can be improved. This is an important fact that software developers should be aware of, as it reduces their ambitions to create perfect code the first time they write it. In this spirit, Kent Beck says that refactoring reflects a new type of relationship with computer programs. Accordingly, when one really understands refactoring, the design of the system is as fluid and moldable in one s fingers as each of the individual characters in a source code file. This skill enables one to see how the code might change and be reshaped in a way that improves its structure (Kent Beck in [Fowler00]).

Some of the most relevant questions to be asked about refactoring are: If one wants to refactor the code, how would one find what to refactor? What clues in the code may help in such cases? Fowler [Fowler00] describes places in the code that require refactoring as places with a bad smell. For each of them, he suggests how to remove the bad smell. For example, in the case of duplicated code (when the same code structure appears in more than one place), Fowler suggests applying Extract Method; the same is recommended in the case of Long Method. However, in the case of Long Method you are recommended to make a new method from the parts of the long method that seem to go well together.

Now that you are familiar with several refactoring activities, the question is, how do you manage the refactoring process? In other words, how is refactoring carried out? Based on his personal experience, Rasmusson [Rasmusson02] says that the team must refactor all the time, to the fullest extent. In the case described in that report, it is declared explicitly that when the team didn t follow this rule, the code became more cumbersome to work with. In practice, it means that in most cases, refactoring is conducted in small and local places, and sometimes a sequence of refactoring actions need to be performed.

Task  

Give an example of a sequence of refactoring actions. In what sense does this chain of refactoring actions improve the code?

Refactoring is not a simple task. Instead of continuing to work on your development tasks , you are asked to stop producing new code and continue working on a code that passes all tests, only to improve its quality. In many cases, you are not even sure that you will be one of the developers who will benefit from these improvements. Furthermore, refactoring requires a high level of awareness. Namely, if you are not aware of the fact that you should refactor, you will end up without refactoring. In addition, it is not sufficient to refactor a certain number of times. Rather, refactoring should be interwoven into the entire development process. Metaphorically, we may say that you need to switch between two hats: adding functionality to the code and refactoring.

As with other human beings habits, one refactors or not depending on the culture in which one lives and one s attitude toward refactoring. For example, for an XP team, refactoring is part of the method; it is accepted naturally; it is part of the development routine; and it doesn t feel like an overhead activity. Furthermore, refactoring is tightly connected to the other XP practices, such as unit testing and continuous integration. At the same time, in other development environments, software engineers may:

• Claim that refactoring is an overhead activity and that they are paid to add functionality to the code, not to reshape it;

• Express resistance from different reasons (Opdyke in [Fowler00]). First, as mentioned previously, refactoring should be executed when the code runs and all the tests pass. Thus, it may seem that time is wasted . Furthermore, refactoring may break the passed tests and additional work will have to be invested to fix the code so that all the tests will run again. Second, if the benefits are long term, why exert effort now? In the long term , the developer might not be part of the team to reap the benefits (p. 382).

As can be observed , there are many reasons not to refactor. If programmers believe in refactoring, however, they can also refactor when they are not part of an XP team. In such a case, one should treat refactoring as part of the profession of software engineering. Indeed, several Integrated Development Environments (IDEs ) offer a Refactoring menu that includes actions such as Extract, Rename, and so forth. (See, for example, IntelliJ IDEA at www.intellij.com/idea/ and Eclipse at www.eclipse.org/platform ). This is a clear sign that refactoring has become part of the profession of software engineering. ^[3]

From all that has been said so far, it seems that refactoring is not a simple task from effective, cognitive, and technical perspectives. Furthermore, its benefits are not immediate and it requires a high level of awareness. However, the main message of this section is that programmers should not skip refactoring, partially because software development is a process that cannot be envisioned in advance and the need to reshape our products cannot be neglected. In this case, the analogy to architectural design is clear. Architects sketch many design drafts before they arrive at the final version of their creation. Many details and design decisions cannot be predicted in advance, as they become clear only as the design and coding process proceeds.

Another message of this section is that refactoring may improve the developers programming skills. When programmers reshape the developed software through refactoring actions, they also improve their understanding of software development heuristics.

Discussion

• Discuss connections between the three main topics discussed in this chapter: program comprehension, code inspection, and refactoring.

• Connect the topics discussed in this chapter to the human nature of software teams (people come and go, developers want to gain job security, among other factors).

^[3] Although refactoring has so many advantages, there are cases where it should not be carried out. One of these cases is when the code is a mess and it would be better to start developing it from the beginning.