Refactoring

Purpose

Change the structure of code while provably preserving behavior. The defining constraint is that behavior does not change — if it does, it is a rewrite, and it needs different scrutiny.

When to Use

• Before adding a feature to code that resists the change.
• When a module has become hard to test.
• To pay down a specific, identified cost — not to satisfy an aesthetic.
• After a bug reveals a structural cause.

Capabilities

• Characterization tests to pin down existing behavior, including its bugs.
• Standard sequences: extract function, extract class, inline, replace conditional with polymorphism, introduce parameter object.
• Dependency breaking: seams, adapters, and inversion for untestable code.
• Incremental strangling of legacy paths behind a stable interface.