While developing, requirements change and previous design decisions can be invalidated. A new feature is added, you get it to work, but the structure and clarity of the code can degrade. You could leave it, and the design will slowly rot, or you could improve the design on the spot. Refactoring is about improving the design.

A simple design has these four characteristics, listed in priority order:

• The system runs all the tests.
• It contains no duplicate code.
• The code states the programmers' intent very clearly.
• It contains the fewest possible number of classes and methods.

A good resource for gaining refactoring knowledge is Martin Fowler's book: Refactoring - Improving the Design of Existing Code [FOW99]. Martin discusses the idea of bad code smells, how to detect them, what harm they will do to your software, and how to fix them.

During development, you should look at the code refactoring with an open mind and find its weaknesses. Clarify the code; fix what needs to be fixed. As you discover these smells, you should work to eliminate them before proceeding to the next test case. Save some time before you check-in your code to step back and look it over. Identify duplicate code sections and places where the design intent is not clear.

Refactoring involves making changes to your code which improve its structure without modifying its behavior. Martin Fowler's Refactoring book lists over sixty refactorings to handle particular code situations. The goal of each of them is to reduce duplication in the code base and increase clarity. Leave your code clean, simple, and free from duplication.

As the structure of your code base evolves, you choose names which aid your understanding of the functionality specified by the code. This system of names becomes the vocabulary for your team's discussion of design.