Technical Debt: Rescuing Legacy Code through Refactoring
How can you get a legacy codebase under control and bring it to a new level of maturity? In this post, Jeroen summarizes the lessons learned from years of working on a large legacy web application. This article was originally published by intracto.
Legacy Code Can Be Saved by Refactoring
I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.
No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.
Fear no evil
Fair enough, you didn’t ask for this horrific quest. The blood-covered ‘Here Be Dragons’ sign near the entrance of the code swamp induces a strong urge to call in sick for the next couple of years. At first glance, you’d rather have some light lunch first, and perhaps a leisurely stroll through the meadow after that, than being the petrified peasant to rid said swamp of its monsters.
Unfortunately though, you are forced past the sign by a galant yet firm nudge from the boss, who will stay behind to defend the town and in the process have some light lunch with the duke owning the swamp.
Bar some drastic measures, you can’t change these basic facts. However, you can turn a swamp into a magnificent meadow with just one muddy patch where cows live!
Technical Debt: How Did It Get This Way?
As you poke and prod the area just past the warning sign with a stick, you might wonder: how on earth can anyone have let this happen? Someone must have seen this coming, surely? Were the people who wrote this code that incompetent?
Possibly. But not more so than anyone else. When push comes to shove, however confident people might seem, nobody else knows what they’re doing either.
Incompetence is far from the whole story. The principle at work here is usually referred to with a metaphor.
Code cancer
The idea is that during development of any project, shortcuts will be taken. Ugly hacks will be allowed to get ahead quickly, just this once. This way, a debt is accumulated: code that does the job any way it can but is completely incapable of being maintained properly, let alone built upon.
And so, bit by bit, a project’s code is corrupted. Nobody cares about this as long as they’re not the one having to touch it. But eventually someone has to, and it will probably be you.
This principle is at work in any project, and if it isn’t it most likely means you’re not moving fast enough. Your competition will take shortcuts, getting new features out more quickly. As a result, your precious users will leave, and join the party in the swamp next door and have a Long Island Iced Tea at the cocktail bar there instead of standing in your impeccable square meter meadow you’ve painstakingly created over the past year. Your meadow might be pretty in and of itself, but there’s just not much going on there.
So, any healthy project will accumulate some technical debt, but in order not to go bankrupt — the code getting so hard to maintain it becomes unmanageable — at some point this debt will have to be settled.
That is where the frightened and resentful peasant comes in, forced to pay the debt in the swamp owner’s stead. Paying this debt is often referred to as refactoring: swapping a bit of code with another bit that does exactly the same but can be maintained and expanded more easily.
Continue reading %Technical Debt: Rescuing Legacy Code through Refactoring%
LEAVE A REPLY
You must be logged in to post a comment.