refactoring-patternslisted

# Refactoring Patterns Refactoring is **changing the internal structure of code without changing its observable behavior**. It is not "cleanup whenever," and it is not rewriting. It is a disciplined sequence of small, *named*, behavior-preserving moves, each verified by tests, each committable on its own. Done right it is nearly risk-free; done wrong — without tests, mixed with feature work, or as a big-bang rewrite — it is one of the most reliable ways to ship a regression. This skill is the deep reference for that discipline: the safety net that makes it possible, the named moves themselves, the smells that signal where to apply them, and the trade-offs of when *not* to. Heavy detail lives in `references/`; copy-paste before/after material in `examples/`; a runnable smell detector in `scripts/`. ## The mental model Two hats, never worn at once (Kent Beck's rule): you are either **adding behavior** (new tests go red, then green) *or* **refactoring** (all tests stay green the whole time). Switching hats mid-edit is the root cause of most refactoring disasters, because when a test breaks you can no longer tell whether your *restructuring* was wrong or your *new feature* was wrong. | Question | Refactoring answer | |---|---| | What changes? | structure only — names, shape, location | | What stays identical? | observable behavior, the public contract, test results | | How do I stay safe? | tests green before, green after, green between every step | | How big is a step? | sm