Refactoring¶
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code. Addison-Wesley.
Cited by¶
14 citations across 14 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
This sourceCatalog of safe, behavior-preserving code transformations as progressive structural refinement.
- 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.
Verification¶
This reference passed the adversarial substantiation pipeline: it was checked to exist and to support the claim it is attached to. See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 3 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.worldcat.org/oclc/1057900885 ×1
Registry ID ref:2658bcc194c8 · see in the full table