refactoringlisted

# Refactoring A refactor changes structure while behavior stays identical. The moment behavior changes on purpose, it is a feature; by accident, a bug. Keep the line sharp. ## Method 1. **Secure the net first.** Confirm the tests around the target pass and actually pin its behavior. If coverage is thin, write characterization tests *before* touching anything: capture what the code does now, even its oddities. An odd behavior may be load-bearing. 2. **Name the smell and the target shape.** "Three near-copies of this query builder → one function with two parameters." If you cannot state the after-state in a sentence, you are wandering, not refactoring. 3. **Move in reversible steps, green after each.** Rename; extract function; inline; move; then delete the old path. Each step compiles, passes, and could ship. Twenty two-minute steps beat one two-hour rewrite in every dimension that matters: reviewability, bisectability, abort-ability. 4. **Separate refactor commits from behavior commits.** A reviewer must be able to skim a refactor commit ("no behavior change") and scrutinize the small behavior commit. Mixed commits get neither reading. 5. **Follow the house style,** even where you prefer another. A codebase with one accent is maintainable; your improvement in a foreign accent is someone else's cleanup ticket. 6. **Stop at the target.** The neighboring mess you noticed goes on a list, not into this change. Scope creep is how refactors