Martin Fowler, author of the book "Refactoring: Improving the Design of Existing Code", has recently published an article on his website exploring different workflows to effectively integrate refactoring into daily programming work.
He also talks about how to use the different types and suggests that "to use refactoring in its most effective way, you need to combine all the refactoring workflows so that they flow seamlessly into your development work".
Fowler defines Refactoring as "…a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour".
Joshua Kerievsky suggests in his book "Refactoring to Patterns" that:
By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain.
Although Fowler states that refactoring has become a well-known technique, he suggests that most teams need to better understand the different workflows that could be used when refactoring, so they can apply the best one for each situation.
The SourceMaking website describes the following situations in which you should refactor, based on the rule of three attributed to Don Roberts.
“The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.”
- When adding a function
- When you fix a bug
- As you do a code review
Fowler introduced the "Two Hats" metaphor to explain, or serve as a reminder that during programming tasks sometimes you're adding new features (adding function hat), other times you're improving the quality of your code (refactoring hat). He also states that "during programming you may swap frequently between hats, perhaps every couple of minutes. But...You can only wear one hat at a time".
In the context of this metaphor, Fowler described the first workflow, probably the most widely used, the "TDD Refactoring". It is built upon the cycle: from a green state, write a failing test; then, make it work and finally improve the quality of the code. Urs Enzler from planetgeek.ch details the relationship between test-driven development and refactoring.
"Litter-Pickup Refactoring" is the next one. Fowler proposed its usage when a messy area in the code is found. The principle behind it is "by cleaning up code as we work in it, we make things quicker for us the next time we need to work with it. Perhaps even make it quicker to change now".
Fowler then explained the details of "Comprehension Refactoring". It is all about making the code easy to understand, and thus cheap to use and maintain. A reference to a Ward Cunningham text was used to complement the idea:
Whenever you have to figure out what code is doing, you are building some understanding in your head. Once you've built it, you should move that understanding into the code so nobody has to build it from scratch in their head again.
He also describes three other workflows, which he says are as important as the first three:
- "Preparatory Refactoring" to apply when you start a new task;
- "Planned Refactoring" to apply when you have larger areas on problematic code that need dedication attention;
- "Long-Term Refactoring" to apply when you are about to replace a large module during several iterations.
Have you been refactoring too?