What is Refactoring?

February 27, 2024

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
Accumulation of Technical Debt
New Scaling Needs
New Performance Needs
Changes in Compliance and Security Practices
Right Time to Refactor
Right Way to Refactor
Refactoring Tools
Linters
IDE Tools
Conclusion

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.