refactoring-toward-functional-designlisted

# Refactoring Toward Functional Design ## Overview Most functional codebases are not new. They are imperative or object-oriented systems being moved, module by module, while they keep running. The work is not a rewrite: it is a sequence of small, behaviour-preserving moves, each of which pays for itself, applied to the code you are already editing for another reason. The second half of the job is keeping a design clean once it is right. Designs decay by absorbing requirements they were not shaped for, one reasonable-looking patch at a time. ## When to use - Editing imperative or object-oriented code in a project moving to a functional style - A new requirement does not fit the existing model - A module has accumulated special cases - Deciding whether to patch or restructure - Planning an incremental migration Not for: designing something new, which starts at [functional-design](../functional-design/SKILL.md). ## Core rules 1. **Ask whether the thing should exist before choosing a move for it.** State the requirement in the domain's words. Anything in the code that the sentence did not mention — a flag, a cache, a required call order, an unread field — is complexity you added, and it is deleted rather than moved. Refactoring it is how it becomes permanent: once it has a good name and a test, nobody removes it. See [essential-and-accidental.md](../diagnosing-complexity/references/essential-and-accidental.md). 2. **Refactor where you are already worki