Refactoring: Avoiding Tunnel Vision
Until everything is done, it’s as if nothing is done. To avoid tunnel vision when refactoring: the Strangler Fig pattern, where old and new coexist.
When a car enters a tunnel, an outside observer knows nothing about its location until the car emerges. This kind of “tunnel vision” is a well-known challenge in the field of programming in general and refactoring in particular. It can be summed up in one sentence: until everything is done, it’s as if nothing has been done.
In real life, it’s Lucas who takes on the development of a new feature. It’s estimated at three weeks of work, so Lucas gets to work. Great (actually, no—we’ll see why). As a manager, you check in regularly, but Lucas’s answers sound a little vaguer each time:
I first need to refactor the Redux state because it’s nested, and that doesn’t work for the new feature anymore; I need a normalized state to be able to work on it.
In the meantime, nothing is in production.
This is an obvious risk to your mental health and Lucas’s; it’s also the risk that the work will take longer than it should (Parkinson’s Law: work naturally expands to fill the time available for its completion), but above all, it means you’re completely exposed to the vagaries of corporate life.
Indeed, at the slightest change in priority or budget cut, the work already done is at high risk of being lost. Nothing is ready to go into production; what’s been done is on a branch that, every day, diverges a little more from main and can no longer be merged.
As you’ve probably figured out, rather than one massive, monolithic development effort, you’d be well advised to carry out a multitude of small development tasks and “push” them into production as you go. That’s exactly why (among other reasons) user stories were invented.
But user stories are for new features. How do you handle this in a refactoring context?
Refactoring is always complicated. It touches on the foundations—the structural aspects of the application. It’s common for refactoring to take weeks, or even months or years in the case of complete overhauls. Once again, creating a refactoring branch isn’t an option, because in the meantime, new features are being added to “main.” These are difficult to merge back in because they’re built on obsolete foundations.
In addition to the Mikado Method, your lifeline here will be the Strangler Fig pattern. The principle: to make the old and the new coexist.
To do this, you’ll need a facade, whose role will be to maintain the contract that governs interactions with the outside world. And behind the facade, out of sight, you gradually replace the old with the new.
The refactoring Lucas mentioned could be summed up like this:
- Creating the new state structure “on the side” (reducers, selectors)
- Transferring data one by one from the old state to the new state
- Throughout, the actions and selector signatures stay the same: the state API hasn’t changed.
This pattern is particularly useful in modularization projects, when you’re “breaking up the monolith.” It’s a Herculean task, but the strangler fig pattern brings it within human reach.