Code refactoring is the process of improving code without making any changes to the application’s functionality. Complex and overly long sections of code can be broken down into smaller and simpler pieces, while redundant code can be consolidated into reusable components.
Below we cover what code refactoring is, why it matters and how programmers can implement refactoring best practices.
What Is Code Refactoring?
Code refactoring is the process of improving code without making any functional changes. For a given method, that means the inputs and outputs stay the same but the code inside can be changed. The final product still behaves the same way to the users, but the code will have been cleaned up or upgraded.
Brendan McCollam, engineering manager at tech recruitment platform Codility, said refactoring techniques come down to two general ideas: breaking down complicated code into smaller parts or consolidating code into reusable components.
Another refactoring technique is renaming functions and classes from something generic to something self-explanatory. That type of change may allow developers to get rid of existing comments that describe what the functions and classes do.
What Are the Benefits of Code Refactoring?
Through code refactoring, programmers can remove excessive code, refresh outdated code and make initially confusing code more readable for other developers. These small changes lessen teams’ technical debt by saving programmers from having to fix code later on and enabling developers to easily share and read each other’s code.
Indeed, developers spend more time reading code than writing new code, which is why a major benefit of refactoring is cleaning up code by extracting snippets into their own functions.
“You’re spending maybe 80 percent of your time reading, understanding what’s already there in order to change it,” Nicholas Thapen, founder and CTO of Sourcery, told Built In. “[Readability] really affects the velocity of adding new features.”
Refactoring is also essential to agile development, which follows the principle of continuous improvement. It allows developers to focus on functionality rather than optimization, giving them permission to write the important code without worrying too much about making it perfect — they can always come back later to polish it up.
In this way, refactoring prevents bottlenecks by giving developers room to break projects into separate pieces that are all continuously improved. Rodrigo Pimentel, director of engineering at chat feed provider Stream, said companies even have the option of doing “dark deploys,” where refactoring updates are pushed out to production without any formal notifications after the initial unoptimized code is already deployed. The method works because the functionality of the code isn’t changed during refactoring.
When Should Code Be Refactored?
It’s important to gauge whether your existing codebase truly needs a refactor because there can be negative consequences if it goes wrong. Even if a piece of code is badly written it doesn’t necessarily need refactoring, Thapen said. That’s because code that runs well and doesn’t get updated won’t cause developers any new problems.
Existing codebases should only be refactored if the code needs to be changed fairly often and the changes seem to always cause problems. At that point, developers should determine the extent of the refactor.
The best way to do that is by reading code, said Shlomi Vaknin, founding engineer at customer relationship management platform DevRev. Developers who educate themselves by reading a lot of code at their company can develop an intuition for how to refactor well.
“It’s very important to learn about what code looks like and to develop your personal sense of code elegance,” Vaknin told Built In. “That will get you a gut feeling of what kind of code you can easily follow — what you consider to be good code, readable code, maintainable code.”
Code Refactoring Best Practices
Plan for Refactoring During Sprint Planning
Refactoring significant chunks of existing code works best when time is specifically reserved for it within sprints. Pimentel said refactoring should be scoped just like any other aspect of development.
Developers should determine the scope of the refactoring work before they start, then reassess the situation based on new knowledge gained from refactoring. If the scope increases dramatically it may be better to abandon it early.
Refactoring work that has a small scope will probably be successful because developers are likely only refactoring their own, recently written code. As the scope widens, repercussions on the codebase could begin affecting other developers.
Development teams can get ahead of the problem by designating time for refactoring, Pimentel said. Refactoring work should be tracked with tickets just like normal development — otherwise, the team’s metrics can be thrown off and lead to a cascading series of problems. If a team only tracks feature development and expects to squeeze in refactoring on top of two weeks’ worth of features, the team will probably not complete all their tasks for the sprint.
Have a Good Test Suite
Developers agree on the importance of testing when doing refactoring. The functionality of code shouldn’t change after refactoring, so tests are a perfect way of making sure that’s true. Ideally, test suites should be as comprehensive as possible.
“If you don’t have a good test suite, it’s almost like stepping out on a rickety wooden bridge — you want to step one step at a time and test each step as you go,” McCollam said. “If you have a test suite, then you can tear out all of the underpinnings and rebuild it. As long as the tests still pass, you know that everything still works.”
It’s also a good idea to update tests as the refactoring progresses. Developers may be adding additional code that doesn’t affect the functionality but still needs to be tested. Additional tests can also help future developers if the codebase ever needs to be refactored again.
And as a last line of defense, the proper use of version control can be a simple way to contain any damage done by complications from refactoring.
“Committing [the code] often really, really helps,” Pimentel said.
Frequently Asked Questions
What is an example of a code refactor?
An example of a code refactor is taking a long, confusing method and breaking it down into smaller segments. A team can assign a method to each segment, making it easier to spot duplicate code and update the code as needed.
Is refactoring code worth it?
Refactoring code is worth it only if there’s a clear need for it and programmers use proven methods. Otherwise, it can result in unnecessary work and possibly disrupt the original function of the code.
What is the difference between code optimization and code refactoring?
While code refactoring is focused on simplifying code and making it easier to read, code optimization is concerned with finding ways to reduce the amount of resources — like memory and compiling time — that code requires.
