Refactoring Protocol
Principle: CHANGE STRUCTURE, NOT BEHAVIOR.
If behavior changes, it's NOT refactoring -- it's a feature or bugfix.
When to Refactor
| Refactor When | Do NOT When |
|---|---|
| Code works but hard to understand | Code doesn't work yet |
| Duplicated code | No tests exist |
| Long methods (> 50 lines) | Under time pressure |
| Deep nesting (> 3 levels) | "Just because" |
Safety Protocol
- •Tests MUST exist before refactoring
- •Tests MUST pass before each change
- •Only small steps (one change at a time)
- •Run tests AFTER each change
- •Commit AFTER each green test
Workflow
code
1. VERIFY -> All tests pass 2. IDENTIFY -> What to refactor 3. PREPLAN -> Check file size limits (standard-file-size-limits rule) 4. PLAN -> Small steps 5. EXECUTE -> One step 6. TEST -> Tests after step 7. COMMIT -> Commit if green 8. REPEAT -> Next step
Common Patterns
| Code Smell | Refactoring |
|---|---|
| Long Method (> 50 lines) | Extract Method |
| Duplicate Code | Extract Method/Class |
| Long Parameter List (> 4) | Parameter Object |
| Deep Nesting (> 3 levels) | Guard Clauses |
| Magic Numbers | Extract Constant |
Anti-patterns (FORBIDDEN)
- •Big Bang: rewriting entire module at once
- •No Tests: refactoring without test coverage
- •Mixed Changes: "while I'm here, let me fix this bug too"
- •Premature Abstraction: abstraction for code used once
Golden Rules
- •TESTS FIRST -- no tests, no refactoring
- •SMALL STEPS -- one change at a time
- •TEST OFTEN -- after every change
- •COMMIT OFTEN -- after every green test
- •BEHAVIOR UNCHANGED -- same inputs -> same outputs