By Benjamin Eberlei, first published at Tue, 28 Nov 2017 09:43:09 +0100
Download our free e-book "Crafting Quality Software" with a selection of the finest blog posts as PDF or EPub.
You can also buy a printed version of the book on Amazon or on epubli.
When you are beginning to consider refactoring your big legacy codebase towards a new software design, then it is not uncommon to feel helpless after estimating this to be a huge terrifying 2-5 years project.
To help solve the problem of not knowing where and how to begin, we have had great success using a decision matrix to decide how each part of the legacy code should be changed in such a refactoring project. Two main factors should influence your refactoring decisions:
The change rate of the code (module, class, function)
The business value of the code (module, class, function)
What to refactor?We start looking at the top right corner of the matrix, where you find high business value code with a high change rate. Realistically this is the code that started the discussion of a large refactoring project in your team. While the risk is high in changing this code, so are the benefits:
Better software design allows to on-board new developers easier
(Much) higher test coverage reduces risk to break code or introduce bugs
High software quality reduces implementation time for future changes and new features
If your company considers software to be a primary function and profit driver, then it should be simple to sell your manager or boss onto the benefits.
But the truth is that every software project consists of a large bulk of essential "boilerplate" use-cases such as administration backends, third-party system bridges and many others that are neither considered "high business value" nor does their code change a lot. This code falls into the bottom left section of the matrix and should not be touched, at least until you already consider the refactoring project a success and improved all the other code.
Often this part of the codebase can make up 50% or more of the total lines and "removing" them from consideration in the refactoring project can simplify the process greatly and increases your chance of success.
The two quadrants where either change rate or business value is low are not as simple to decide on as the two extreme cases.
In the high business value, but low change rate case, you might be tempted to start refactoring the full code towards a new software design, but I would always advise against this to keep the refactoring scope small.
Instead you could introduce a thin facade / adapter layers that wrap the legacy code with a new and improved API instead. This way you can call this code from your new design with high business value and high change rate, without having to interact with the legacy code at all.
In the low business value, but high change rate case, refactoring is important to fight yourself free from the usually expensive and time-consuming process of changing legacy code. But because the code has no primary value for the business, investing energy in building a new software design might be too big a time investment.
Instead you should work on improving the quality of individual units within this legacy code and start writing or improving the tests for them.
So how do we start working a refactoring project with this matrix?
Qafoo experts can kick-start your team with a continuous refactoring process. We can show you how to improve your source code quality on the go and help you to get rid of the big quality chuckholes in your construction site.
The easiest way is too extract code that is changing a lot into new functions or small objects and then integrate them back into the legacy code. We have written other blog posts on how to do these simple refactorings with concrete examples:
Based on these and other refactoring strategies you are starting a sort of spearhead refactoring effort into your high change rate code base and gradually improve its quality.
After a while you have a significant amount of refactored code so that you might get an idea of a new software design that you want to move that code to. With an idea for a new software design when working on high business value code you can then go one step further and refactor towards this a new software design that can lead to even better code with the 3 benefits I listed before..
Stay up to date with regular new technological insights by subscribing to our newsletter. We will send you articles to improve your developments skills.
Jan on Thu, 30 Nov 2017 13:07:12 +0100
Nice systematical approach. I like that you've reused the Eisenhower matrix :)
Link to commentOne minor issue: the link to "How you can successfully ship new code in a legacy codebase" has a trailing quote -> 404.
http://bigessaywriter.com/blog/is-it-easy-to-write-essay-about-yourself on Fri, 09 Mar 2018 11:15:05 +0100
I like this strategy! It's a new but pretty interesting approach! Thanks for sharing your posts with concrete examples included!
Link to commentranjan on Tue, 20 Mar 2018 09:08:13 +0100
thankyou
Link to commentShruti Gupta on Wed, 24 Oct 2018 12:53:44 +0200
Great information.Keep posting such useful stuff.Will remain tuned to more such updates.
Link to commentThank You
http://www.zoommyprice.com/product/htc-desire-12-plus-32gb-rom-3gb-ram-cool-black
http://blog.zoommyprice.com/index.php/2018/10/23/new-i-phones-unleashed-in-september/
http://www.zoommyprice.com/product/dell-inspiron-3542-15-6-inch-laptop--core-i3-4005u-4gb-500gb-hdd-ubuntu-intel-hd-graphics-4400---black