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.