Qafoo GmbH - passion for software quality ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :Author: Benjamin Eberlei :Date: Tue, 28 Nov 2017 10:25:54 +0100 :Revision: 8 :Copyright: All rights reserved How to Refactor Your Legacy Code: A Decision Matrix =================================================== :Abstract: 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… :Description: 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… :Keywords: Refactoring, Object oriented Design, Business Value 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) .. image:: /blog/images/what_to_refactor_matrix.png :alt: What to refactor? :align: center 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. First Steps in Refactoring Effort --------------------------------- So how do we start working a refactoring project with this matrix? .. note:: 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. __ /services/workshops/refactoring 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: - `Refactoring Singleton Usage to get Testable code `_ - `Extracting Value Objects `_ - `How you can successfully ship new code in a legacy codebase `_ - `How to perform Extract Service refactoring when you don't have tests `_ 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.. .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79 Trackbacks ========== Comments ======== - Jan at Thu, 30 Nov 2017 13:07:12 +0100 Nice systematical approach. I like that you've reused the Eisenhower matrix :) One 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 at 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! - ranjan at Tue, 20 Mar 2018 09:08:13 +0100 thankyou - Shruti Gupta at Wed, 24 Oct 2018 12:53:44 +0200 Great information.Keep posting such useful stuff.Will remain tuned to more such updates. Thank 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