What is Refactoring?
Overview
Refactoring is the process of updating code without changing its API or underlying functionality. It’s a natural process that almost any code must undergo on some interval. The exact interval or right time is discussed below. In some cases, the changes to legacy code are so great that an entire redesign that includes infrastructure and API is required. This extent of what could be considered a refactor (and is commonly referred to as a refactor) should technically be called an overhaul, redesign, or re-architecture.
Table of Contents
Contributors to this Need
There are several contributors that push the needle towards the need to refactor. They are discussed below.
Accumulation of Technical Debt
Technical debt accumulates when code is written in a way that is not as maintainable as it should be, because either:- A new code change reveals that the existing design needs to be updated.
- Code is written hastily to meet deadlines.
- Some other capacity reason (knowledge, talent, etc).
This technical debt can reach a point where additional changes take too long to complete compared to the effort relative to a refactor.
New Scaling Needs
The need to refactor due to new scaling needs could potentially be a sign that the original design was flawed… but, not necessarily. It’s also possible that the original design was very simple and was able to support new scaling needs for a long enough time to merit its simplicity (rather than building complexity that is not utilized for many years to come).
New Performance Needs
As businesses grow, their customers’ expectations may change. This increased expectation may compel changes to services that improve performance.
Changes in Compliance and Security Practices
As businesses grow, the need to meet various compliance expectations grows. This may be because of changes to a business’s model or expansion into new markets and territories.
Right Time to Refactor
The right time to refactor is before any of the contributors mentioned above reach a breaking point. This may be from business pressures, or it might be from technical pressures.
Right Way to Refactor
It’s important to assure full unit and integration testing of the feature being refactored. This reduces the risk of introducing regressions to a feature or service. To learn more about testing, see Testing in Software Engineering.
Refactoring Tools
Linters
Refactoring could take the form of improving code formatting. This is a very small step in refactoring and linters go a long way to automating and guiding the way.
IDE Tools
IDEs often have tools to help in refactors, such as propagating any changes in a variable or method name.
Conclusion
This is a quick introduction to Refactoring. It’s an area where experience plays an important role. Observing the dynamics of a team, a service, and its codebase over time can be difficult to new eyes. The initial design of a project goes a long way to deciding when its first refactor might be necessary. Setting the correct expectations and requirements are critical to gaining the necessary information to create a design that matches the capacity and trajectory of the service and its customers.
To be updated with a closer look at when it’s the right time to refactor.
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.