refactoring

To refactor code safely, identify a single structural problem like duplication or tight coupling, then apply small, reversible steps such as extracting responsibilities or renaming for clarity. Validate after each step using existing tests to ensure externally observable behavior remains completely stable.

You need to refactor existing code during maintenance when tech-debt evidence, code reviews, or implementation friction show that current structure is increasing future cost or risk. Target specific issues like oversized functions, hidden dependencies, or unstable seams that impede future changes across modules.

Refactoring does not count as feature development or defect fixing. The strict constraint is that externally observable behavior must stay stable; if the behavior changes during the process, the work is classified as feature development or defect fixing, not refactoring.

The best way to reduce tight coupling and code duplication is to define the invariant that must remain, then perform reversible refactors like extracting or moving responsibilities in small, verifiable steps. Prove design improvements by demonstrating lower coupling and clearer boundaries through tests.

You should document design improvements after a code refactor to prove gains like simpler control flow and clearer boundaries, ensuring future maintenance benefits. This documentation validates that the structural changes achieved their goal of lowering coupling and reducing future implementation friction.