Arguments For and Against Code Refactoring

Code refactoring is an inevitable part of any project’s life cycle. As a project develops, its code becomes outdated. So it’s not a question of whether you should or shouldn’t refactor (the answer is always yes, you should). The question is when it’s time to refactor. In this article, we help you figure that out.

When refactoring is a must

Code refactoring is the process of restructuring code to improve its readability and reduce its complexity without making any changes to its external behavior.

Let’s consider the cases when to refactor your code.

#1 You make significant upgrades or are faced with legacy code

The development of a project shouldn’t stop when it’s launched. With more users, code gets slower and new bugs appear, requiring fixes. Besides, over time, you may want to add new functionality, use a new technology, or replace outdated libraries.

But what should you do if your project’s codebase is bulky? What if you have to deal with legacy code? The answer is that you should refactor it. Follow the advice below to get the best results when refactoring legacy code:

• Don’t start refactoring right away. When you inherit legacy code, you or your team may (and most likely will) think the code is ugly. However, if it does the job, it’s not that bad. Don’t dive into refactoring and trying to fix all the weaknesses until you get acquainted with the code. There’s a chance it has dependencies you’re unaware of.
• Start small. Don’t refactor the whole codebase at once. It will take too long and your team will get stuck in refactoring process without a chance to do any other work. It’s better to plan small changes in every sprint. This will allow your team to improve the code and develop it at the same time.
• Follow the Red-Green-Refactor principle when adding new functionality. Agile software development methodology calls for adding new functionality using the Red-Green-Refactor principle. Red means create tests, Green means write code to pass those tests. After red and green phases, developers can refactor the code, making it laconic and clean.

Always leave the code behind in a better state than you found it.

Uncle Bob Martin

#2 There are lots of bugs

Fixing bugs without refactoring can lead to even more bugs, plus hours of tedious work.

Fixing one or a few bugs in your codebase may not require refactoring at all. However, a codebase with a lot of bugs (legacy code, for instance) can be what’s called spaghetti code. You fix one thing and another crashes.

Make sure the code you’re going to debug doesn’t have hidden dependencies or repetitions and is easy to read. If it does and/or it’s hard to read, refactor it and then debug.

#3 You need to make code robust to changes

It’s definitely time to refactor your codebase when you add new features and bugs appear in parts that weren’t changed and functioned perfectly before. It means your code is flaky.

To avoid this situation and create a codebase that’s resilient to changes, developers should follow principles of test-driven development and behavior-driven development as well as the SOLID and DRY principles.

If the codebase already exists, you can improve it with refactoring.

#4 There’s repetitive code

Repeated code is a common problem when several developers are working on different parts of the same project. Code gets repeated when developers simply don’t know that someone else has already written code they could reuse.

Such duplications lead to cases when a bug is fixed in one place but not in all other places. Fixing bugs in such code can become a nightmare, especially when a developer doesn’t understand which version is correct. Duplications also make code clumsy and slow.

The Don’t Repeat Yourself (DRY) principle, commonly used in Agile software development methodologies, aims at making all elements independent so a change to any single element of a system won’t require a change to other logically unrelated elements.

According to the DRY principle, code refactoring is the main cure for duplicated code. Refactoring helps to find repetitions and make code more laconic.

Martin Fowler describes the rule of three, which explains when to refactor, in his book Refactoring. He says that the first time developers do something, they should do it straightforwardly. The next time, if they do something similar, they can duplicate the existing piece of code. The third time, they should refactor.

#5 Code is hard to read

The main aim of refactoring is to improve the readability of code, making it more efficient and maintainable.

In many cases, it’s not even necessary to restructure code to do that. A developer can just rename a few functions or variables using more straightforward names and that will be enough to make the code more readable.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

#6 There’s technical debt

Technical debt is often compared with monetary debt. When you don’t repay it, the interest compounds. Even if you don’t develop your software actively, the debt still gets bigger. Why? Because developers who worked on the project leave it, and those small sacrifices to code quality that they made to meet business deadlines or enter the market faster will show up in their full strength.

Technical debt causes consequences on different levels. Here are just some of them:

• New features take a long time to implement
• Broken deadlines and budgets
• Inaccurate estimates
• Vendor lock-in, when it’s almost impossible to change a software development company

There’s no way to avoid technical debt. Nevertheless, you can take some measures to minimize it. The Agile methodology calls for constant refactoring during development as the main weapon against technical debt. However, most managers and developers rarely get a chance to start a project from scratch. With an existing project, what they should do is schedule regular refactoring tasks for every sprint and reduce technical debt until the code is clean and can be easily read by a new team of developers.

Wrapping up

Refactoring is one of the most effective tools to keep your code quality high. That’s why you should make it a part of the software development routine and stop considering refactoring as an optional step to be taken from time to time.

The word ‘refactoring’ should never appear in a schedule. Refactoring is not a story or a backlog item. Refactoring is not a scheduled task. Refactoring is immediate and continuous. It’s like washing your hands in the bathroom. You always do it.

Uncle Bob Martin

When not to refactor

Refactoring has to be an essential part of the development process. However, there are some cases when refactoring is a waste of time and money. Let’s find out when you should consider some other options apart from refactoring.

You don’t have enough code coverage

Code refactoring can cause more harm than good if you don’t have all the necessary tests in place.

When dealing with legacy code that doesn’t have proper test coverage, you can’t be sure the code you’re refactoring works correctly. If you can’t check how your changes influence the code, it’s better to postpone refactoring. Otherwise, you can easily mess something up.

The Agile methodology, which helps developers create high-quality software fast, also promotes test-driven development (TDD). This development approach teaches developers to write automation tests before the code itself and requires refactoring after each iteration. Using a test-driven development approach, you’ll have tests to run after each little step of the refactoring process.

It’s not clear where to move

When you have to deal with legacy code that doesn’t look very pretty, you understand that it needs to be improved. However, it’s not always obvious where to start and what to change to improve it.

Without a clear plan for refactoring, any attempts to change anything can lead to new bugs and complications. In such a case, it’s better to leave the code as is (if it does the job) and try to get to know it better.

After a while, when all the dependencies show up and you know the code inside and out, you’ll understand what parts of the code you need to refactor and how to do so successfully.

Module needs to be revamped completely

Sometimes, it’s much easier to rewrite a module in an app from scratch than to try to refactor and save it. Here are the cases when you can seriously consider this possibility:

• Your development team can barely understand the code
• Debugging is becoming more and more challenging
• More time is spent on fixing bugs than on implementing new features
• Any changes send ripple effects through the module
• Code is too messy and is difficult to maintain
• You know there’s a technology or framework that can dramatically reduce the amount of code in the module

If even one of the cases mentioned above describes the situation you’re in now, it’s probably time to retire the old code.

If you’ve decided to rewrite a module in your app, well-written tests can make your life significantly easier. With the proper tests, it’s relatively straightforward to create a new, more easily maintainable module. If you don’t have tests, start with writing a detailed specification and only then proceed to code.

You need to launch fast

If you want to enter the market as soon as possible (and there are a number of reasons why you may want to), you can ignore refactoring.

For instance, say you want to launch a minimum viable product (MVP) as a proof of concept or to validate a business idea and show it to your investors.

In such a case, bugs are irrelevant: they can be fixed later, or you can rebuild the MVP into a full-fledged system by applying TDD and Agile principles.

Another possible reason is a desire to get ahead of competitors and hit the market faster. Refactoring will only slow you down. You can sacrifice it to win the audience.

The bottom line

Code refactoring is an inherent part of the modern software development process. It should be considered a separate process only when you inherit an old codebase that’s difficult to read and maintain. In all other cases, refactoring should be part of the routine.

Don’t forget to subscribe to our blog, and feel free to ask us any questions below!