Refactoring Legacy Code

You’re feeling overwhelmed, staring at your behemoth legacy codebase and realizing it’s going to be a monstrous 2-5 year project to refactor the thing. But fear not, my friend! We’ve got a secret weapon that’ll help you conquer that mountain of code - the decision matrix.

The matrix helps you decide what to do with each part of the legacy code, taking into account two crucial factors: the rate at which the code changes (class, function, module) and its business value.

First, let’s look at the top right corner of the matrix - the high value, high change rate code. This is the code that’s likely sparked the idea of a big refactoring project in the first place. It might be risky to change, but the rewards are worth it: better software design that makes it easier to onboard new developers, more robust testing to avoid breaking things, and higher software quality that saves time in the future.

And if your company views software as a primary profit driver, selling this to your manager or boss should be a cakewalk.

But what about the rest of the code? There’s a lot of “boilerplate” use-cases in every software project, like admin backends and third-party system bridges, that are low value and low change rate. This code belongs in the bottom left of the matrix, and it’s best to leave it alone until you’ve already conquered the rest of the codebase. Trust me, ignoring 50% or more of the code will simplify your refactoring project and up your chances of success.

The two middle quadrants - high value, low change rate and low value, high change rate - are trickier to decide on. In the first case, you might be tempted to refactor everything, but don’t fall for it! Keep the scope small and instead, create a thin facade or adapter layer to wrap the legacy code with a new API. And in the second case, you want to improve the code quality, but since it’s low value, don’t waste time refactoring it into a new design. Instead, focus on improving individual units and writing or enhancing tests.

First Steps

So, how do we get started with the matrix? Easy peasy - start by extracting code that’s changing a lot into new functions or objects, and gradually work your way up the high change rate codebase. As you make progress, you’ll eventually get a sense of a new software design you want to move towards. And when you’ve got that, go ahead and refactor to that new design - you’ll end up with even better code and all the benefits I listed before.