dmitryprg-ai 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