When Should We Refactor?
"Refactoring is something I do every hour I program"
🆕 Preparatory Refactoring: Making it easier to add a new feature
Would the work be easier if it was structured differently?
The best time to refactor can be before adding a new feature to the code base.
When fixing a bug, refactoring can improve the code and reduce the chances that it will appear again.
🧠 Comprehension Refactoring: Making Code Easier to Understand
Before code can be changed, it requires understanding of what it does.
By refactoring, we move the understanding from our head into the code itself.
This understanding will be preserved longer and be visible to our colleagues.
Refactoring leads to higher levels of understanding that would otherwise be missed.
🗑️ Litter-Pickup Refactoring
🏕️ Boy Scout Rule: Leave the camp site cleaner than when you found it.
A variation of comprehension refactoring
Code is understood, but the implementation is poor
e.g. logic is unnecessarily convoluted, duplicated, etc.
If we make the code a little better each time we pass through, over time it will get fixed.
Over the course of several months, this process can achieve large refactoring efforts without requiring planned refactoring.
🗺️ Planned vs Opportunistic Refactoring
Opportunistic
Refactoring performed while adding a feature or fixing a bug.
It's part of the natural flow of programming.
Refactoring is NOT an activity that's separated from programming.
Preparatory, Comprehension, and Litter-Pickup Refactoring are all Opportunistic.
Both ugly & clean code need refactoring.
Planned
Planned refactoring should be rare.
If a team has neglected refactoring, if often needs dedicated time to get a code base into a better state.
Sometimes a problem area grows to a point where it requires concerted effort to fix.
Should we separate refactoring into different commits/PRs?
As with most things in software, "it depends"
Should be a Team decision.
It's only worthwhile if it makes life easier.
Advantages:
Reviewed & approved independently.
Disadvantages:
Refactorings are often closely interwoven with adding new features and it's not worth the time to separate them.
Removes the context for the refactoring, making the refactoring harder to justify.
📆 Long-Term Refactoring
Most refactoring can be completed within a few minutes - hours at most. Large refactoring effort can take weeks or months.
We should be reluctant to do dedicated, planned refactoring here.
An Alternative to Planned Refactoring:
Agree to gradually work on the problem over the course of the next few weeks.
Anyone working in the "refactoring zone" applies little changes in the direction of improvement.
✅ Refactoring in a Code Review
Code reviews help spread knowledge through a Team.
Experienced developers pass knowledge to those with less.
Refactoring helps when reviewing someone else's code.
Helps get more concrete results from a code review.
Suggestions are implemented there and then.
Refactoring in the context of a Review (PR) can be thought of as pair programming.
👨💼 What Should I Tell My Manager?
Managers should be familiar with Design Stamina Hypothesis and encourage refactoring on a regular basis.
When Managers lack technical awareness, don't tell them.
Software Developers are professionals.
Our job is to build effective software as rapidly as we can.
We're paid for our expertise in programming new capabilities fast, and the fastest way is by refactoring.
⛔ When Should I Not Refactor?
Sometimes refactoring isn't worthwhile.
If code is a mess, but we don't need to modify it, then there's little need to refactor it at that moment.
Refactoring benefits are realized when we need to understand how the code works.
Is it easier to rewrite then refactor? This decision requires good judgement & experience that can't be summarized into a simple rule or piece of advice.
Last updated