Refactoring is the practice of continuously improving the design of existing code, without changing the fundamental behavior.  When combined with rigorous Test Driven Development and Continuous Integration, refactoring becomes a powerful mechanism to ensure the best possible system.

Techniques

Refactoring should only be done while a programmer is in a particular piece of code for some specific reason. It is not advisable to go scouring the system for refactoring opportunities, unless the system is enough of a legacy that some headway needs to be made. More often than not, just refactoring code we are already looking at will keep us plenty busy. The essential technique is to look for what is commonly referred to as code “smells,” something that stands out as not quite the best it could be. Prior to modifying the code to eliminate those smells, write tests around the code to make sure you don’t break something along the way. Make the modifications and run all tests. If the tests all pass, check the code in. Be sure to bite off only very small pieces of refactoring at a time. The older or more tightly-coupled a system is, the faster a large refactoring can snowball into a major undertaking. Ideally, the average refactoring should only take a few minutes. In addition, avoid the temptation to redesign a large piece of code under the auspices of refactoring. Large redesigns should only be undertaken when absolutely necessary. Consider refactoring to be tidying up the house, where major redesigns are extreme makeovers.