Refactoring (Deep Workflow)
Refactoring changes structure, not behavior. Safety comes from small steps, fast feedback, and verification (tests, golden outputs, or controlled manual checks).
When to Offer This Workflow
Trigger conditions:
- Code is hard to change; duplication; unclear module boundaries
- Need to prepare an area for a new feature without mixing behavior change
- Paying down tech debt with management expecting “no user-visible change”
Initial offer:
Use six stages: (1) clarify goal & scope, (2) establish safety net, (3) plan increments, (4) execute with reviewable commits, (5) verify behavior, (6) document & follow-ups). Confirm test coverage and release pressure.
Stage 1: Clarify Goal & Scope
Goal: Why refactor now—reduce coupling, enable feature X, remove dead code, improve naming.
Exit condition: Explicit non-goals (no feature changes in this effort unless separately scoped).
Stage 2: Establish Safety Net
Goal: Prefer characterization tests for legacy; golden outputs for data pipelines; use snapshot tests sparingly.
If tests are weak
- Approval tests, short exploratory scripts, or pair review with domain expert
Stage 3: Plan Increments
Goal: Small commits, each leaving the codebase working (not necessarily perfect).
Practices
- Move code, then change behavior in separate steps (Fowler-style when helpful)
- Separate mechanical renames from logic edits for reviewability
Stage 4: Execute With Reviewable Commits
Goal: Each PR/commit tells a story; avoid thousand-line “cleanup” dumps.
Stage 5: Verify Behavior
Goal: CI green; compare outputs for batch jobs; manual smoke on critical paths when needed.
Stage 6: Document & Follow-Ups
Goal: ADR or short module README for new boundaries; tickets for remaining debt accepted consciously.
Final Review Checklist
- [ ] Scope and non-goals explicit
- [ ] Safety net matches risk
- [ ] Incremental, reviewable steps
- [ ] Behavior verified
- [ ] Follow-up debt tracked
Tips for Effective Guidance
- Keep refactor commits separate from feature commits when possible.
- If behavior must change, it is not “pure refactoring”—plan as a migration with communication.
- Under hotfix pressure, minimize refactor scope or defer.
Handling Deviations
- Strangler refactors: maintain adapters at boundaries until cutover is complete.