Refactoring is about improving the quality of code. When the time comes for maintenance, refactored code is easier to read and maintain. Here’s how http://www.refactoring.com defines the process of refactoring:
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.” [emphasis mine]
Notice I’ve emphasized the notions of small and little. Refactoring is about making a series of minor changes to make the code better while ensuring its integrity. The goal of refactoring is:
- Making small, precise, surgical changes
- Enhance code base quality
- Ensuring outside dependencies that use your refactored code work are not disturbed
I hear a lot of developers throw the term refactoring around to mean everything from a bug fix to complete rewrites of an application or part of it. Refactoring is not:
- Maintenance, although you would likely refactor during maintenance sessions.
- Modifying the design of software
- Rewriting an entire page, class or module. Refactoring is about making small changes to improve quality.
- Fixing bugs. Your code should work before you refactor it, but as always, we can’t expect code to be 100% bug free.
When and Why Refactor?
Code bases evolve significantly not just during maintenance but during development as well. Because the code is constantly changing, it is very easy to go into a downward spiral and to bake into your software some bad stuff, especially while under the gun. It’s a lot like gardening – you plant a garden but must continuously tend to it to keep it healthy and in top condition. Keep in mind that mistakes happen, junior level programmers may not know of the best way to do things, at times it is difficult to smoothly solve a problem, etc… Even considering many great approaches to software development (such as Agile, TDD, Scrum and XP) things can go wrong. Code can get ugly. Knowing this, we should realize our options and use refactoring as a technique to keep quality levels high.
Considering that all code can be improved, anytime that we modify or touch a code base we should look for code that needs to be refactored. In general, we’ll do this during maintenance, but we can also do it during development cycles so that we can code for quality out of the gate.
Resources on Refactoring
If you’re looking for resources on exactly how to refactor, what ‘code smells’ are and how to rid them, I’ll be likely posting more examples in the future. In the meantime, here are some books & sites:
Complete: A Practical Handbook of Software Construction by Steve McConnell
Refactoring: Improving the Design of Existing Code by Martin Fowler
