Which technique should I reach for? Use this decision tree and cheat sheet to quickly find the right approach for your situation.
Click the type of change you're making to see technique recommendations.
Question 1
What's the situation?
The code isn't structured to receive it cleanly
It's user-facing and needs gradual rollout
It requires lots of boilerplate + infrastructure
Tests don't adequately cover the area
What's the situation?
The code is tangled in a large file
A hard-coded value needs to change
Test coverage is insufficient
What's the situation?
Swapping one component for another (same interface)
Need high confidence the new version is correct
Migrating an entire subsystem piece by piece
What's the situation?
Multiple consumers need updating
The function signature needs evolution
What's the situation?
Always — schema changes and code changes are separate PRs
All 12 techniques at a glance. Blue links have full worked examples.
| Technique | One-Liner |
|---|---|
| Preparatory Refactoring | Make the change easy, then make the easy change |
| Feature Flags | Ship the code dark, turn it on later |
| Branch by Abstractionsoon | Introduce an interface, then swap behind it |
| Strangler Figsoon | Grow the new around the old |
| Scaffold First | Ship the structure before the logic |
| Parallel Implementationsoon | Run new alongside old, compare, switch |
| Expand/Contract | Add the new, migrate consumers, remove the old |
| Data Migration Decouplingsoon | Schema and code are always separate PRs |
| Test-First Decompositionsoon | Ship the safety net before the change |
| Extract and Delegate | Move it first, change it second |
| Configuration-Driven Behaviorsoon | Make it configurable first, configure second |
| Interface Segregationsoon | New contract alongside old, migrate, retire old |
Techniques are often chained together. These are battle-tested sequences for common scenarios.
5 of 12 techniques fully documented — more coming soon. Browse all techniques →