| name | refactoring |
| description | Improve code structure without changing behavior. Use when refactoring, cleaning up, optimizing, simplifying, extracting methods, or reducing complexity. Requires tests BEFORE refactoring, small steps, commit after each green test. |
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
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
