Refactoring¶
Fowler, M. (1999/2018). Refactoring: Improving the Design of Existing Code. Addison-Wesley.
Cited by¶
15 citations across 15 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Additive Bias
- In software it is codebase accretion, where deletion is rare and formal refactoring sprints are needed to remove what additions did not earn.
This sourceEstablishes refactoring as the named, separately scheduled discipline of removal/restructuring without changing function, the standard software remedy for codebase accretion.
- In software it is codebase accretion, where deletion is rare and formal refactoring sprints are needed to remove what additions did not earn.
- Conservation Event
- The reference state is the earlier clean-architecture commitment — a documented module boundary, an interface contract, a layering rule that the code once honored.
This sourceRefactoring as bounded, behavior-preserving change that restores a violated design/architecture (the reference state) and pays down accumulated technical debt (the decay trajectory).
- The reference state is the earlier clean-architecture commitment — a documented module boundary, an interface contract, a layering rule that the code once honored.
- Culminating Point
- In software, a large refactor pushed past the team's capacity to hold the partial state in mind begins introducing more bugs than it removes.
This sourceCautions that a large refactor pushed past the team's capacity to hold partial state in mind begins introducing more defects than it removes.
- In software, a large refactor pushed past the team's capacity to hold the partial state in mind begins introducing more bugs than it removes.
- Internal Intensification
- Software engineering: refactoring inside existing modules to absorb new functionality versus adding new modules; intensification cost is regression risk and cognitive load, expansion cost is cross-module duplication, coupling growth, and integration complexity.
This sourceCanonical treatment of refactoring inside existing modules to absorb change, whose discipline has migrated into broader organizational-change practice.
- Software engineering: refactoring inside existing modules to absorb new functionality versus adding new modules; intensification cost is regression risk and cognitive load, expansion cost is cross-module duplication, coupling growth, and integration complexity.
- Intervention Stack Accretion
- In software systems, feature creep, configuration matrices, dependency stacks, observability layers, and security controls accrete into technical debt, with refactor cycles, deprecation policies, and scheduled rewrites as the deliberate inverse.
This sourceTreats technical debt accreted through feature additions and the deliberate refactor/deprecation cycles that serve as the inverse operation.
- In software systems, feature creep, configuration matrices, dependency stacks, observability layers, and security controls accrete into technical debt, with refactor cycles, deprecation policies, and scheduled rewrites as the deliberate inverse.
- Maintenance
- Fowler (2018) makes this distinction sharp in his treatment of refactoring as behavior-preserving structural maintenance, separate from feature work.
This sourceCanonical treatment of refactoring as behavior-preserving structural maintenance; sharpens the distinction between maintenance (preserves function) and feature improvement (extends capacity).
- Fowler (2018) makes this distinction sharp in his treatment of refactoring as behavior-preserving structural maintenance, separate from feature work.
- Managed Retreat
- In software and codebases, deprecating and removing a module whose maintenance burden exceeds its usage on an announced schedule precedes the failure or upgrade-blocking it would otherwise cause.
This sourceTreats deprecation and removal of obsolete code on a planned schedule when maintenance burden exceeds its value.
- In software and codebases, deprecating and removing a module whose maintenance burden exceeds its usage on an announced schedule precedes the failure or upgrade-blocking it would otherwise cause.
- Maneuver
- Chess positional play ("accumulate positional advantage before attacking") maps onto software refactoring ("make the change easy, then make the easy change").
This sourceFrames refactoring as repositioning the codebase ('make the change easy, then make the easy change') so subsequent features become localized and cheap.
- Chess positional play ("accumulate positional advantage before attacking") maps onto software refactoring ("make the change easy, then make the easy change").
- Naming Convention
- The structural remedy is enforcement tooling — linters, formatters, and pre-commit hooks that detect and correct violations mechanically — which is what turns a paper convention into a sustained one.
This sourceEstablishes naming and code-style discipline and the role of automated tooling (linters, formatters) in mechanically enforcing conventions — the load-bearing community-commitment leg of a code-naming convention.
- The structural remedy is enforcement tooling — linters, formatters, and pre-commit hooks that detect and correct violations mechanically — which is what turns a paper convention into a sustained one.
- Progressive Refinement from Core Model
- The red-green-refactor cycle is progressive refinement applied to code: each cycle's baseline is the previous passing test suite, and each refinement must preserve it.
This sourceCatalog of safe, behavior-preserving code transformations as progressive structural refinement.
- The red-green-refactor cycle is progressive refinement applied to code: each cycle's baseline is the previous passing test suite, and each refinement must preserve it.
- Refactoring
- Software engineering (origin): the canonical case, with named operations — extract method, rename, introduce parameter object — backed by automated test suites that pin the external behavior so internal change can proceed continuously.
This sourceCanonical definition of refactoring as behavior-preserving change, with a named catalog of operations (extract method, rename, introduce parameter object) backed by tests.
- Software engineering (origin): the canonical case, with named operations — extract method, rename, introduce parameter object — backed by automated test suites that pin the external behavior so internal change can proceed continuously.
- Refinement
- Software engineering & design: Stepwise refinement (Wirth's approach from specification to implementation), refactoring (restructuring code without changing behavior, treated systematically by Fowler (2018)), design refinement through testing and user feedback, iterative deployment in agile and continuous-delivery models, debugging and performance tuning.
This sourceCanonical treatment of refactoring as behavior-preserving structural maintenance; sharpens the distinction between maintenance (preserves function) and feature improvement (extends capacity).
- Software engineering & design: Stepwise refinement (Wirth's approach from specification to implementation), refactoring (restructuring code without changing behavior, treated systematically by Fowler (2018)), design refinement through testing and user feedback, iterative deployment in agile and continuous-delivery models, debugging and performance tuning.
- Retention Under Removal Uncertainty
- Dependency mapping, dead-code analysis, the deprecation cycle, sunsetting policy, garbage collection, clean-room re-implementation, the Chesterton's-fence audit (the explicit version of "why was this here?"), and zombie review are recognizably the same moves whether applied to code, law, regulation, curricula, schemas, or attics.
This sourceTreats dead-code identification, dependency analysis, and safe-removal technique, including the labor of confirming a code element is unused before deletion.
- Dependency mapping, dead-code analysis, the deprecation cycle, sunsetting policy, garbage collection, clean-room re-implementation, the Chesterton's-fence audit (the explicit version of "why was this here?"), and zombie review are recognizably the same moves whether applied to code, law, regulation, curricula, schemas, or attics.
Mechanisms¶
- Identity and Associativity Test Suite
- The suite is the license the refactoring workflow needs before it dares regroup anything.
This sourceTreats a solid self-checking test suite as the practical safety net that makes behavior-preserving refactoring possible.
- The suite is the license the refactoring workflow needs before it dares regroup anything.
- Small-Step Refactoring Workflow
- Its strength is fearlessness in dangerous code: it makes defects trivially localizable, reverts nearly free, and the system continuously shippable, which is what lets a team restructure legacy no one fully understands.
This sourceExplains that small behavior-preserving refactorings reduce error risk and avoid leaving the system broken during restructuring.
- Its strength is fearlessness in dangerous code: it makes defects trivially localizable, reverts nearly free, and the system continuously shippable, which is what lets a team restructure legacy no one fully understands.
Verification¶
Does it exist? Confirmed. This work's ISBN resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Not recorded. Neither this nor any other of the 15 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 4 other ways.
- https://martinfowler.com/books/refactoring.html ×4
- https://www.informit.com/store/refactoring-improving-the-design-of-existing-code-9780134757711 ×4
- https://www.martinfowler.com/books/refactoring.html ×1
- https://www.worldcat.org/oclc/1057900885 ×1
Registry ID ref:2658bcc194c8 · see in the full table