Refactoring Decisions

Before refactoring, check each gate. If any gate fails, stop and do the suggested alternative instead.

Refactoring means behavior-preserving code changes — nothing more. If the behavior changes, it's not a refactor.

The 6 Gates

Gate 1: Is this actually a refactor?

Refactoring = behavior-preserving changes only. If you're fixing a bug, adding a feature, or handling a new requirement, that's not refactoring — call it what it is.

If no: Stop. Discuss what system change is needed. Don't disguise feature work as refactoring.

Gate 2: Do the examples fit the planned refactor?

If the improvement matches "almost all" cases but creates exceptions, don't force the abstraction. Three similar lines of code is better than a premature abstraction with an exception.

If no: Investigate a different code smell, or wait for a new requirement that makes the pattern clearer.