One of the skills a samurai developer must develop is knowing how to apply refactoring in their day-to-day work. When starting the software development journey, one tends to follow the axiom “If it works, don’t touch it, or it might break.” This fear naturally arises from inexperience and the context in which one works. However, I believe that as professionals, we must pursue the ideal of continuous improvement, and to achieve that, we must overcome that fear. It’s good to have a protocol on how and when to act to produce better code.
This is what Richard Fowler talks about in his refactoring talks. I will now summarize the compilation of ideas he promotes, hoping it serves as a guide for you as well.
The Red and Green Circle
The common practice in TDD is to write the test first and then the functionality, which abstracts us from the implementation. Then one proceeds to develop the functionality and make the test go from failure (red) to success (green).
It is common that as we progress in the development process, we encounter code that is ugly. This may be because it is old or because it was not coded clearly.
The Two Hats Come into Play
Richard Fowler talks about two work styles when sitting down to develop: the construction hat, which one wears when adding new functionality to the system, and the improvement hat, which is used when performing a refactoring task.
So, you found code that is ugly, hard to read, or too complex. The question is, do you ignore it or do something to change it? The answer would be to strive for improvement and change it (as long as it meets certain characteristics that I will describe later).
Richard Fowler talks about two work styles when sitting down to develop: the construction hat, which one wears when adding new functionality to the system, and the improvement hat, which is used when performing a refactoring task. During development, we will be forced to switch hats depending on what we want to do. The important thing is not to do both things at the same time because it can lead us to make changes without being sure that we can run a battery of tests to ensure that the system is functioning correctly.
Workflows of Refactoring
Changes that do not alter functionality or have a small impact should be made immediately. Such as renaming methods, variables, and functions to make them clearer, and extracting methods to better encapsulate their behavior. Fowler refers to this practice as “The Boy Scout Rule,” based on the principle of “Always leave the campsite cleaner than you found it.” This refactoring method is called Litter-Pickup Refactoring.
The Preparing Refactor
This type of refactor often occurs when we want to add a new feature, but we realize that the current code does not easily allow for adding this feature. However, by making some changes, it may be easier to implement the new feature. This type of refactor is essential to keep the code clean and promote easier addition of future features, reducing development time.
The Planned Refactor and Long-Term Refactor
So far, we have talked about refactors that are done during our day-to-day work and do not require meticulous planning and organization. However, there is a type of refactor that does require these measures: planned refactors. These are refactors that are planned, estimated, and have a medium to large size or a significant impact on the system’s architecture and functionality, requiring careful attention during their execution. Fowler warns that these types of refactors are “bad” in the sense that a well-designed system should not need this type of refactor, and medium to large refactors can be carried out by breaking them into smaller tasks and iterating to accomplish them. This type of refactor is called long-term refactor. However, it is not wrong for an occasional refactor of this kind to arise.
When should I apply refactoring?
Up to this point, one might think that my idea of refactoring is to be a kind of bulldozer that cleans up everything in its path. Well, yes and no. To decide when to apply a non-simple and quick refactor, one must consider a series of things:
- How much time will it take?
- How often will I encounter this “bad smell” code in my day-to-day work?
- Am I in a moment where I can carry it out?
For example, if we are dealing with a problem in production, with alarms going off and messages coming through all communication channels, clearly we are not going to start doing refactors that take more time to generate a solution. Here we don’t change hats; the goal is to create the fix.
As for how often I will come across the code, that is the metric I pay the most attention to because the modules that change the most should be the clearest and cleanest ones, as they facilitate my task of understanding what they do and being able to modify or add more features to them. Code that doesn’t have much impact and is unlikely to be encountered again doesn’t require the effort; after all, time is a resource and must be managed in the best possible way.
Justifying the Refactoring
Fowler also talks about how to explain to our bosses or leaders the need for refactoring to be part of development, just like testing. It is true that we can cite reasons such as readability or speed, but these justifications are purely technical and tend to dilute as they go up the ladder of management. However, there is one justification that always prevails: money.
Instead of presenting a technical diatribe of justifications, it is easier to reach people with things they are more familiar with, for example:
“I need to refactor X because it will make it faster to add functionality Y, and if we want to add Z tomorrow, it will be easier too.”
“This refactor reduces our expenses on the database, CPU, hosts, etc., by minimizing resource usage.”
The moment we keep going back and forth about performing refactorings is the moment we lose the battle.
The post From Chaos to Order: Refactoring Fundamentals for Better Results first appeared on Samurai Developer.
Top comments (0)