Refactoring is the disciplined practice of restructuring existing code to improve its design, readability, and maintainability without changing its external behavior.1
What it is
The defining constraint is behavior preservation: a refactor reorganizes the how while keeping the what identical. Typical moves — popularized by Martin Fowler’s catalog — include renaming for clarity, extracting a function or class, inlining a needless indirection, removing duplication, and breaking up a class that has taken on too many responsibilities. Each is a small, safe step rather than a sweeping rewrite.1 Refactoring is triggered by code smells: duplication, long functions, large classes, tangled dependencies, and other signals that the code resists change. Left unaddressed, those smells accumulate as technical debt that slows every future change.
Why tests matter
Because a refactor must not alter behavior, you need a way to prove it didn’t — and that is the job of tests. A solid suite of fast unit tests (run automatically by CI/CD) lets you restructure boldly and catch any accidental behavior change in seconds. This is also why refactoring is the third beat of the test-driven development cycle: red, green, then refactor on a green suite.
How it connects
Refactoring is how the quality principles get applied to code that already exists. You refactor toward clean code, toward DRY, KISS and YAGNI, and toward SOLID — improving names, reducing coupling, and introducing the right abstraction only once it has proven itself. Done continuously in small steps, it keeps a codebase healthy; deferred indefinitely, it becomes a costly rewrite.
Sources
-
Code refactoring — Wikipedia, for the behavior-preserving definition and Martin Fowler’s catalog of refactorings. ↩ ↩2