Everything You’ve Always Wanted to Know About Refactoring

…without ever daring to ask.

The definition of refactoring is unambiguous: refactoring consists of modifying an implementation without changing the associated behavior. Therefore, when a new feature leads to a preliminary refactoring, it pays to separate the time spent on refactoring, which leaves behavior unchanged, from the time spent implementing the feature itself. And thus, to make two commits, for greater clarity.

Why refactor?

As we’ve just seen, refactoring is often “driven” by the feature that comes right after it. In other words, the need for refactoring arises from the gap between the model underlying the current codebase and the one underlying the feature. For example, an application might associate one course with one teacher and one class. This works very well until the day you want to allow students to work in small groups for more personalized attention from the teacher. At that point, the model becomes obsolete and the code unsuitable. It might be tempting to anticipate these changes, but it’s best to avoid doing so.

Another cause of refactoring: technical debt. It must be paid off, or else it will hinder the codebase’s ability to evolve in the medium term. Paying off technical debt is precisely what refactoring entails. Debt can be incurred unintentionally, due to a lack of knowledge of development best practices, or intentionally to meet a deadline. Beyond that, it’s important to understand that debt is inherent to programming, because architecture and coding conventions emerge in part despite all our efforts to anticipate them. The moment we touch the keyboard, we create debt, and the need for refactoring becomes unavoidable.

But enough talk… let’s refactor 🧰 ⚙️ 🔧 Even more so than development in general, refactoring requires a methodical approach. Here are three methods you can always fall back on, like lifelines.

Avoiding Regressions with the Golden Master

A major concern must be to avoid introducing regressions. You therefore need a safety net, that is, tests that will quickly detect any unintended side effects of your refactorings. The problem is that unit tests, if any exist, will be of no use to you since the implementation will change completely. You can rely on higher-level tests (integration, end-to-end), but you’ll need to write more of them than you normally would in order to explore all possible paths through them, a task usually handled by unit tests.

Well, let’s not kid ourselves: it’s still most likely that there are no tests at all 🤣 In such a situation, one approach is to create a set of business logs, known as the “Golden Master” because it must remain stable despite successive refactorings. It follows, then, that these logs must not contain any implementation-related information.

Avoiding tunnel vision: the Mikado method and the Strangler Fig pattern

Then comes another challenge: often, a first refactoring depends on a second, which in turn depends on a third, and so on. If you’re not careful, you’ll quickly find yourself trapped in a vortex from which it will be very difficult to escape: successful compilation becomes a distant memory, and regressions silently pile up. The Mikado Method addresses this problem by suggesting that you first map out the dependencies between refactorings, then traverse the resulting tree in reverse, starting from the leaves.

Naturally, all this work takes time, a lot of time. Usually weeks or months; in the worst-case scenario, years. Working in parallel with production exposes you to a serious risk of tunnel vision and puts your work at risk: code that isn’t in production is code on borrowed time. To remedy this, Martin Fowler brought back from his vacation in Australia the Strangler Fig pattern, which allows for the gradual replacement of legacy code with refactored code in production.

Other considerations come into play, which only become apparent as you work on the code over time. But to delve deeper into these three refactoring methods, I recommend the course “The Art of Refactoring.”