Chapter 3: Refactoring - By Example

Overview

In Chapters 1 and 2, we briefly touched on the subject of refactoring. This chapter gives a detailed treatment of this topic because refactoring is one of the fundamental aspects of test-driven development and a very useful practice in its own right.

Refactoring is an activity aimed at improving the internal structure of existing code without making externally visible changes to the functionality. Why would such changes be useful? (After all, there is an age-old engineering adage: If it ain t broke, don t fix it. ) Are we suggesting fixing a problem that does not exist? Is refactoring just another way to waste your time and money? The simple answer is no.

Note  

Refactoring is a long- term , cost-efficient, and responsible approach to software ownership.

We argue that refactoring is the way to make your long-term software ownership less painful. Through refactoring, design intent becomes clearer as the code evolves. Without refactoring, the code s clarity will degrade over time, eventually becoming unintelligible.

Let s look at some code to clarify the point. We will demonstrate the basic ideas behind refactoring on a simple piece of code that is in need of some maintenance.

More Info  

For additional reading on this topic, read Martin Fowler s book: Refactoring: Improving the Design of Existing Code (Addison- Wesley, 1999). This book is the source of the refactoring names that are used in this chapter. As a side note, the examples in Martin s book are in Java but are straightforward enough to follow if you know C#.