Refactoring

Refactor code in small, behavior-preserving steps so the next change becomes easier, safer, and cheaper.

When To Use

• You need to improve structure without changing externally observable behavior.
• A feature is hard to add because the current design is awkward.
• A bug fix is blocked by confusing, tangled, or duplicated code.
• You need to understand legacy code before touching it.
• You want a small, safe refactoring plan instead of a vague cleanup pass.

When Not To Use

• You are intentionally changing product behavior.
• The code is ugly, but you do not need to touch it.
• A rewrite is clearly cheaper and lower risk than incremental restructuring.
• There is no practical way to verify behavior and the risk is unacceptable.