refactoring-safely

# Refactoring safely — changing shape without changing behaviour Refactoring is a behaviour-preserving transformation. If behaviour changed, that was not a refactor, it was a rewrite with optimistic branding — and the reason large restructures fail is almost always that the two were done in one step. ## The rule that makes the rest work **Never restructure and change behaviour in the same commit.** Alternate deliberately: refactor (green → green, no behaviour change), then change behaviour (with a new test). When both happen at once, a failing test cannot tell you which half broke it. ## Before touching anything: the net Legacy code is code without tests, regardless of age. So: 1. **Characterization tests first.** Not tests of what it *should* do — tests of what it *does*, including behaviour you consider wrong. Their job is to detect change, not to judge it. Wrong-but-tested behaviour gets fixed later, on purpose, in its own commit. 2. **Cover the seams you are about to cut**, not the whole file. Coverage of the region under the knife is what matters. 3. **Confirm they fail when you break something.** A characterization test that passes against deliberately broken code is worse than none — run that check once. 4. **Know how to revert.** Small commits, one transformation each. ## Smells, and what each one actually indicates | Smell | Underlying problem | Transformation | |---|---|---| | Long function | Several jobs in one scope | Extract function, split by...