Many people use 'refactoring' to mean any kind of code cleanup, but that's not what refactoring is intended to mean.
As we'll consider, the original definition of the term is more precise — it refers to a specific way of changing code.
Refactoring is a disciplined approach to improving the internal structure of software to make it easier to understand and cheaper to modify, without changing its observable behavior.
The origins of refactoring go back to the early 1980s (Leo Brodie, Ward Cunningham and Kent Beck), and was first shown in literature by the early 1990s (Ralph Johnson, William Opdyke). Going further, John Brant and Don Roberts built the 'Refactoring Browser' which was the first automated refactoring tool.
Then, in the late 1990s, with the emergence of the Agile movement, the need for and interest in the subject exponentially increased, and it was widely spread by Martin Fowler's book, which became the reference for refactoring.
At the end of the day, it's all about business. The point of refactoring is purely economic.
We refactor because it makes us faster—faster to add features, faster to fix bugs, and ultimately producing more value with less effort.
Otherwise, continuous additions of features and ad-hoc bug fixes without refactoring increase software entropy [Ivar Jacobson], which slows us down and puts business innovation opportunities at risk.
In Fowler's book, he introduces us to Kent Beck's notion of describing the "when" of refactoring in terms of code smells.
The book has a list of code smells, that help us identify code that can be improved by a refactoring.
Supported by high-quality automated tests.
Take incremental tiny steps, then compose those steps into substantial changes.
The code is never broken for a long time: all tests should pass after every small change.
There is a catalog of refactorings in Fowler's book.
Each refactoring in the catalog is explained with a name, its motivation, and step-by-step mechanics.
- Refactoring is distinct from simply changing code.
- Code quality has a direct impact on business innovation.
- Refactoring can help mitigate software entropy.
- Improving code quality can be a safe and rewarding process for everyone involved.