eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

Sue: Why not just get it right the first time?

Eddie: It is very rare for any piece of software to be developed "right the first time." I should qualify that by adding that every programmer I have ever spoken to has said that if given a second opportunity to code a solution they would do it differently. I have met a few arrogant individuals who claim they are so smart they always code the correct solution the first time. Personally, I don't believe they can always be right, and even if they are, they are in a very small minority. Most of us need all the help we can get to ensure we get a good piece of software written. Refactoring is some of that help; it allows us to admit that we are less than perfect and provides us with a tool to enable us to work toward perfection over time.

Deepak: Why not just start again if you know it's wrong?

Pete: Yeah! If we know we will always do a better job the second time around, why don't we build a throwaway prototype and then start again when we have learned the lessons to be gained from this?

Eddie: There are development methods that use this approach, and they appear to work well because the developers can make mistakes in the first version and learn from these mistakes. The problem in my mind is this: Where is the cutoff point? At what stage should we stop prototyping and start building the real application? There are always lessons to be learned as we develop a system.

Chris: If you have the time to build the entire system first and then throw it away and start again, then you are in an enviable position. We are not in that position!

Eddie: Right, most of us developers are working under tight time constraints, and we need some way to incorporate the lessons we are learning back into the code being developed. Refactoring is a mechanism that allows this constant learning to be fed back into improving the software. The prototyping approach doesn't scale when adding new feature to an existing system; it is not feasible to recode the entire solution every time a new feature has to be added. Refactoring allows existing software to be scaled and enhanced over time.

Pete: Why can't I just refactor at the end of the project?

Eddie: So, we can do bigger code "tidy ups" at the end of the project or large periods of coding, but we will lose the benefits to be gained by constantly refactoring. I am not sure I would call this refactoring either. Refactoring is making small changes through the project. By constantly refactoring, we are making the next piece of work we do potentially easier. We will also see patterns emerge more rapidly, and we can then work with those patterns to make the code easier to understand.

Deepak: Why does this help me develop more robust code?

Eddie: Refactoring forces us to review the code we have written and look for ways to simplify it. The very fact that we are reviewing the code is a good starting point for increasing the quality of our software. It has been shown time and time again that code reviews are valuable for improving the code quality. Many of the refactoring techniques that you will learn have been developed because they do enforce robustness in the code. For example, one refactoring replaces an enumerated type with an object hierarchy. This introduces a level of type safety not previously present in the code.

Time to Tidy Your Code

In the early 1990s, I was working on a software project in C; at the end of each deliverable (usually every month), I would spend a few days "tidying up my code." My boss was not overjoyed by this, but I was so insistent about it being important that he let me carry on; he was a smart boss! The tidying up meant that I could get the code into better shape for building the next deliverable, and I have no doubt that helped the project succeed. This tidying up was really a big refactoring exercise. I could see patterns in the software that needed to be improved so the next stage would be easier to develop. Although I insisted on spending three or four days doing this refactoring, I actually didn't like it much. It is boring to spend four days moving code around and not get any new functionality into the system. I did it because, like cleaning the car windows, I wanted to see where I was going more clearly. By doing constant refactoring at the end of each test-code cycle, I was spreading the boredom out into smaller chunks of refactoring throughout the development process.