refactoring-patterns

Refactor a long method by applying Extract Method: pull each logical section into its own well-named method, passing needed locals as parameters. Run tests after every extraction and commit only when all tests pass, so any failure points to the last small step.

Fix duplicated code with Extract Method to share common logic, or Pull Up Method when duplication spans sibling classes. Follow the Rule of Three: tolerate duplication once, note it twice, and refactor on the third occurrence to avoid premature abstraction.

Replace a switch statement with polymorphism when the same type-based conditional appears in multiple methods and new types are added frequently. Each type gets its own subclass implementing the behavior, so adding a type means adding a class instead of editing scattered conditionals.

Refactoring without tests is unsafe because you cannot verify behavior is preserved. First write characterization tests that capture the code's current actual outputs, even if they seem wrong, then refactor freely behind that safety net.

Avoid refactoring when a rewrite is genuinely easier, when the code will be deleted soon, when no tests exist and adding them is impractical, or when the code works and nobody needs to modify it. Polish on doomed or untouched code wastes effort.

Use Branch by Abstraction: introduce an interface over the old component, migrate callers incrementally, build the new implementation behind the abstraction, then switch over and delete the old code. Parallel Change works similarly for renaming widely-used APIs via expand, migrate, and contract phases.