Refactoring is a very well known technique that has been used for years in the software development field. Here are some popular definitions:
“Code refactoring is the process of changing a computer program’s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.”
– Wikipedia
Or, being more concise:
“A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”
– Martin Fowler
My concern with Refactoring is that most people don’t realize that they will have much more benefits if they do it all the time.
As the definition above explains, the purpose of Refactoring is to make code easier to change over time. It doesn’t make sense to keep adding features to your code for, say, 10 months and then stop-the-world for a couple of weeks to refactor it. If you’re doing that, you’re totally missing the point. In this hypothetical situation, not only (1) it would become more complex to make changes in the software over time – and you’d be in trouble for several months – but also (2) at some point of time the team would have to stop and re-engineer everything – because the software would become very difficult to change.
If a team waits for 10 months, or 2 months, or 2 weeks to refactor something, they are doing it wrong. Each time new features are added the code becomes more complex, and it’s necessary to review it as soon as possible to make the necessary improvements. If the team doesn’t do that often, they will become slower and slower each day, they will be less productive and deliver much less features (or value).
The “re-engineer” thing even worse. First, teams that stop to make huge refactorings are delivering nothing to their customers while doing that because they’re too busy fixing their own mess. It’s definitely bad to pay a software team to deliver nothing. Second (and more important), huge refactorings are often risky, because they change a great amount of code and software components, usually introducing bugs and unexpected behaviors.
To avoid all these bad things, you must do refactoring every day, all the time!
Every time you make a change, you must look for an opportunity to make an improvement. If you keep doing that, your code will always be clean, maintainable and easy to modify. Remember the TDD cycle: Red-Green-Refactor? Don’t miss the refactor part, do it all the time!
In my experience it takes no more than a few minutes to refactor if you are doing it in small chunks all the time, and more importantly, this will keep you from stopping to make huge and risky software re-writes.
