safe-refactor

Topics in the source

• Safe Refactor
• 1. Baseline
• 2. Plan
• 3. Small steps, green between each
• 4. Don't sneak in behavior changes
• 5. Language-specific notes
• 6. Finish

Refactoring = changing structure without changing behavior. The whole skill is about proving behavior didn't change. Run the tests that cover the target code; record the result. Also run type check and lint (tsc --noEmit, eslint; mypy/pyright, ruff). If coverage of the target is weak, write characterization tests first: tests that pin current behavior (including weird behavior) for the main inputs. Commit or stash-point here so you can roll back. If tests are failing before you start, tell the user — don't refactor on a red baseline. Write a short plan listing each transformation and the risk. Show it to the user if the refactor touches more than 3 files or changes a public API. Find all usages before renaming/moving anything: Watch for dynamic usages grep might miss: string-based lookups, getattr, re-exports in index.ts/init.py, templates, config files. Do one transformation at a time and rerun tests after each: Extract function / component / hook Rename (symbol + all usages + imports) Replace conditional chains with lookup tables or early returns Remove dead code (confirm it's truly unused first) Split a large module; keep a re-export at the old path if external code imports it I

This is an excerpt. Refer to the complete source and its current requirements.