The second chapter of Refactoring to Patterns has a short introduction to Refactoring. I already posted a short introduction to refactoring from Applying UML and Patterns.
The book describes 3 main motivations for refactoring:
- Make it easier to add new code
- Improve the design of existing code
- Gain a better understanding of code
One of the goals of refactoring is to produce human-readable code. If you find yourself writing a lot of comments within your code to explain what it does, you may want to spend time refactoring the code so it is understandable on its own. Martin Fowler said it best:
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
The key to refactoring is that you basically refactor as you code and that you refactor in small steps. If you keep putting off refactoring, you end up getting design debt (code smells) that will probably never go away, because it is difficult to justify to the boss to spend 2 - 3 weeks worth of refactoring after the fact.
You refactor in small steps so you don't end up adding defects into the system that may take you hours to untangle. After each refactoring you re-run your unit tests to verify your refactoring did not cause a defect in the system. You then continue the cycle of refactoring and re-running unit tests until you have eliminated the code smells.
There you have it - a short introduction :)