The Case for Refactoring
“Software development is like writing a novel,” Geoffrey Grosenbach, vice president of innovation at Pluralsight told the Software Development Times in an article earlier this month. “You write a first draft and you can see where it is going, but it is not cleaned up yet so you go back and you edit that novel a little more, and a few more times until you have a completed book. Refactoring is this idea of treating software as a drat, going back through the code, rewriting it to do the same thing it was always doing, but improving it so it is more useful to oneself and to other people who are going to work on it later.” (Click here for the article)
An inescapable fact of software development is code written by one developer will need to be maintained by someone — and often that someone is somebody else. That’s why all code should be written in a way that is readable and maintainable. But let’s be realistic, business demands don’t always allow you to write ideal code all of the time. Your first efforts shouldn’t be your last. Code refactoring plays an important role in minimising technical debt, improving code quality and increasing future productivity.
What is refactoring?
Let’s take a step back and have a look at what is code refactoring. Put simply, it is a code improvement process in the software development lifecycle. The goal is to change the structure of code in order to improve the maintainability of the code, rather than improving the performance or functionality of the software.
It involves decoupling modules, splitting big ugly methods into easy to read smaller ones and introducing new data structures or design patterns in order to simplify extension. And its pivotal role in paying off technical debt incurred earlier in the software development lifecycle should be noted.
The key feature of refactoring that differentiates it from other code improvement tasks is that functionality change is not the goal. When you sit down to optimise code, you’re looking to make the system more performant. When you sit down to fix defects, you’re looking to make the system function more correctly. When you sit down to refactor, you’re looking to make the system easier to extend and maintain in the future.
Refactor code as early as possible
Refactoring code is one of those tasks where the benefits are hard to quantify because the benefits are longer term and not immediately noticeable. For this reason it can be difficult to convince your managers or clients to spend precious project time or money on code refactoring. But, as many quality software developers will attest to, it is important and time should be made for it.
Try to do major refactoring as early as possible during the software development lifecycle. Refactoring can be a risky process, which is why you should avoid doing it towards the end of a project — just in case you introduce defects in to production.
As with writing unit tests, refactoring while system changes are performed is an effective technique for improving a codebase. How does it work? When a software engineer starts work on a new feature, they identify areas of the code related to the new work which could benefit from additional clarity and simplification. Then they make structural improvements to the system and surrounding functionality by refactoring. In this case, substantial improvements to a pre-existing system can be made without much budget impact. And it goes without saying, the investment of time will pay itself off well into the future.
Identify which areas of your codebase will benefit most
In order to increase the return on time spent code refactoring, it is important to identify which areas of your code base will benefit most from being refactored. There are a number of factors that can come into play here:
- Age of the code.
- How often does the code change?
- Are there lots of bugs in the code?
Look at finding areas of your code where you regularly need to make changes. A little refactoring to some regularly changed code can make for a marked increase in efficiency of development later. Say you spend 4 hours improving a piece of regularly edited code, and as a result now only need spend 5 minutes making a change there instead of 30. That time saving will quickly add up if you’re making a lot of changes there.
Remember, code refactoring is important
Refactoring is an important part of software development. While it doesn’t make a noticeable change to the software from an end user perspective, it helps to reduce costs of future development. Regular refactoring of your code will make your life as a developer easier, and benefit your clients by saving them time and money in the long run.
You should do your best to find time for refactoring whenever possible, ideally early in a development cycle. Focus on refactoring code prone to change, and which is currently difficult to maintain. Ensure that refactoring does not introduce new functional issues, or harm performance of the system.
About F1 Solutions
For over 20 years F1 Solutions has been building quality software solutions for Federal and State Government departments, small and large not-for-profits, and businesses in Canberra and across Australia. We also provide organisations with trusted IT support and advice, as well as a range of other services.
- Software Development
What others say About Us
"F1 Solutions works hard to understand our business requirements, which change over time, and respond with innovative and flexible solutions — examples include our business continuity platform, virtual technology environment [and] scalable network platform. We feel that F1 genuinely supports the mission and vision of the St Vincent de Paul Society and this shows through in all our interactions."