Refactoring is the process of changing the internal structure of code without altering its external behaviour. The software still does the same thing from the user’s perspective, but the code becomes cleaner, more readable, more maintainable, or more performant.
Renaming a confusingly named variable, breaking a 500-line function into smaller pieces, or removing duplicated logic are all examples of refactoring.
You’ll hear this when…
“We need to refactor this” means the code works but is hard to maintain, extend, or understand. “Refactoring sprint” is a period dedicated to cleaning up code rather than adding features.
Refactoring is an ongoing practice, not a one-time event. Good development teams refactor continuously as part of their normal work — improving code structure whenever they touch it. The alternative is letting code quality deteriorate until it becomes painful to work with, which is how technical debt accumulates.
The key constraint
The defining rule of refactoring: behaviour doesn’t change. If you’re also fixing bugs or adding features, that’s not a refactoring — it’s a modification. The distinction matters because pure refactorings are safer (nothing should break if you’re not changing behaviour) and easier to review. Automated tests are essential for refactoring with confidence, because they verify that behaviour hasn’t accidentally changed.
Source: Martin Fowler, Refactoring: Improving the Design of Existing Code (1999, 2018)