Refactoring Rhythm
Refactoring typically cycles between two distinct modes:
- Small, local changes that enable larger structural improvements.
- Large, cross-cutting changes that improve the overall design.
Before the big changes can happen, many small adjustments are needed to make them feasible. What developers often won’t admit is that they usually don’t know what those large changes will be at the outset. Instead, the initial small edits serve a dual purpose: they not only prepare the codebase but also help the developer re-familiarize themselves with the system.
Refactoring, in this sense, is a kind of guided search through the structure of the code. Each change in the early phase acts as a probe that helps the developer uncover constraints, recognize patterns, and identify weak points in the design.
If we were to chart the value of changes over a refactoring cycle, the pattern would look something like this:
- Early stage: a burst of small, low-risk changes as the developer orients themselves.
- Middle stage: larger, higher-value changes begin to emerge, interleaved with smaller supporting edits.
- Late stage: a return to smaller changes, as the obvious large improvements have been exhausted.
I need to get better at recognising when I’ve entered that final phase. Continuing to make low-impact changes at that point often leads to diminishing returns and wasted effort.