refactorlisted

# Refactor Refactoring is changing code structure without changing behavior. The key word is _without_. Every technique here is designed to preserve correctness while improving the code's shape. ## The cardinal rule: tests must be green before you start If the tests aren't passing before you refactor, you don't have a baseline. You can't tell whether a broken test is the result of your change or was already broken. Fix failing tests first — that's a separate job from the refactoring. If there are no tests for the code you're about to refactor, write enough to cover the behavior you're going to disturb before touching anything. You don't need 100% coverage — you need enough that a behavioral regression would show up. ## Identify the seam before cutting A seam is a place where behavior can change without editing the code that uses it — typically a function boundary, interface, or injection point. Find the seam before you start cutting. The seam defines the scope of your refactoring: you're rearranging what's inside it while keeping the seam's behavior the same from the outside. If the code you need to refactor has no obvious seam, your first task is to introduce one safely (often by extracting a function or class around the region you want to change). ## Work in small, reversible steps Each step should: 1. Leave the tests green 2. Be a single logical change (rename, extract function, move, inline, etc.) 3. Be independently reviewable Don't do five things in one commi