What is code refactoring and why should you agree to it?

What is code refactoring?

In software development, code refactoring is a process of replacing a piece of a code with a new one - one that is easier to read, scale or maintain. But code refactoring is not synonymous with rewriting - refactoring is a way of altering the structure of a digital product without changing its behavior. How is that possible? In a “perfect world” scenario, code refactoring is done via a series of basic actions called micro-refactorings, none of which is enough individually to affect the integrity of the code or cause any errors.

Why do developers want to do another code refactor?

When working with a digital product, it’s impossible to avoid a small amount of often harmless technical debt. In the case of significant technical debt, code refactoring works as a way to pay that debt off. Some developers might want to look out for so-called code smell - a set of characteristics that could imply that the code has some hidden problems. In this scenario,refactoring can work as a treatment for major underlying issues without affecting the functionality of the product. But there are other signs that code refactoring might be necessary, such as:

• reducing the time and effort required for adding new features
• new requirements - old technical decisions become obsolete
• security (the vulnerabilities of some external libraries)

In order to maximize the effectiveness of code refactoring it’s best to implement it as a part of regular maintenance - continuous refactoring is much cheaper and easier than extensive refactoring performed once per year.

How can code refactoring benefit your digital product?

When performed properly, code refactoring produces code that is easier to understand, scale, and improve. It can also change the way developer looks at the code in terms of potential improvements, such as:

• fixing bugs and deep-rooted problems
• further development & maintenance
• debugging
• adjusting to changes of business goals (ie: product moves to another phase of its FCPD)

How to refactor code in the right way

Refactoring always comes with a risk that the new code won’t work as well as the old. In order to avoid creating any new bugs, it is important to prepare a series of so-called unit tests - a process of testing small, isolated pieces of the code, called units. Code refactoring can proceed once a unit test confirms that it’s safe for the entire code.

You might be also interested in the article:

Tech

Black-Box vs. White-Box Testing

Code refactoring at Boldare - an example

Recently, our team worked with a client on a digital product that we improved using code refactoring. The product itself was made up of two components used to monitor and manage home energy systems: a web portal and a mobile app. One of the features was meant to display voltage, power levels, and the flow of electricity between different elements of the circuit. The energy flow visualization had two issues:

• occasionally, the app was showing values that were incorrect; this was an indicator of deep-rooted bugs lurking somewhere in the code,
• there was a need to implement new features, but doing so with the current architecture would be a demanding task with the risk of creating more bugs.

The idea was simple: to restructure the code in a way that would make it easier to find and fix the current bugs and have an easier way of managing future ones. This relates to the concept of cognitive complexity, which determines how difficult the code is to intuitively understand. Ideally, the team wanted to keep cognitive complexity as low as possible as it would make the code more clean and transparent for anyone involved in the project.

To do so, our developers singled out every element of the code so they would flow independently from each other. This way, changing the data combination of one element would not affect any other element. As a result, the product owner improved their understanding of the product and could work with developers more effectively. From a business perspective, code refactoring for this digital product had a number of benefits:

• the logic of the code was improved and multiple bugs were fixed, including the one with incorrect values,
• roadblocks that stood in a way of introducing new features were removed,
• developers improved their understanding of our clients’ business,
• the team improved their understanding of the technology behind the product.

The last benefit was the one that our team appreciated the most. It is not often that the software development team gets to talk to the engineers responsible for the hardware involved in a home energy system. These conversations were very productive and will bring further benefits in the future as our team will carry over these experiences to other projects.

Code refactoring - is it a good thing?

From the developers’ point of view, code refactoring is a broad subject that gets both more complex and interesting with each implementation. From the perspective of the product owner, or anyone else involved in the digital product, it’s something that should not be feared but welcomed. It shows that the development team understands the digital product on a deeper level and is thinking about solutions that yield results in the long run. Which, in our case, turned out to be so much more than we were expecting.