dream-zjk Refactor
When to use
- A function grew too large or does too many things.
- The same logic is duplicated across files.
- Names no longer reflect what the code does.
Workflow
- Lock behavior first. Ensure there is a test suite (or write one) that captures the current contract. Refactoring without a safety net is rewriting.
- Pick one improvement and do it as a single, reviewable step.
- Prefer mechanical moves: rename, extract function, inline, introduce parameter. Avoid changing logic while restructuring.
- Run the tests after every step. Small, frequent checkpoints beat one big rewrite.
- Delete dead code rather than commenting it out.
Constraints
- No behavior change. If you fix a bug along the way, do it in a separate commit.
- Don't introduce new abstractions for hypothetical future needs (YAGNI).
- Keep the public API stable unless the change is explicitly about the API.
Definition of done
- Tests are green and coverage did not drop.
- Diff is dominated by structure changes, not logic changes.
- The code is measurably simpler (fewer branches, less duplication).