Refactoring in small, verified steps

Goal

Make existing code more readable and cheaper to change, and show step by step that its observable behavior stays the same.

Prerequisites

Fowler's definition: a refactoring is a change to the internal structure of software that makes it easier to understand and cheaper to modify without changing its observable behavior. This requires tests that pin down that behavior. If they are missing, write characterization tests first: call the code with representative inputs and record today's outputs as the expected values, even if they look odd. You also need the catalog on refactoring.com with named steps such as Extract Function, Inline Function, Move Function, Rename Variable or Introduce Parameter Object, and a test suite that runs in seconds.

Steps

1. Name the target state and the smell you want to remove (long function, duplicated code, data clump); write that sentence down as a draft of the commit message.
2. Apply a single named refactoring, using the editor's automated refactoring where possible, which handles renaming and extraction across all call sites.
3. Run the tests. Red means: undo the step (editor undo or, if the last green state is committed, git restore .) rather than debugging forward; either the step was too big or the behavior is in fact not covered.
4. Commit after each sensible group of green steps, with a message that starts with refactor: and does not promise any change in behavior.
5. Put behavior changes strictly in their own commits, either before or after. Reviewers must be able to rely on a refactoring diff being behavior-neutral; then they can read it for structure instead of line by line.
6. Stop as soon as the smell is gone. Speculative generalization ("we'll surely need this later") is a new smell, not a refactoring.

Expected result

A series of small commits, each green and each reviewable in minutes, which together produce the intended structure, and a test suite that has become more complete along the way.

Limits and test basis

Tests only protect what they cover; runtime, memory use and concurrency behavior can change unnoticed. Restructuring across module boundaries requires the same discipline plus a plan, such as the strangler fig pattern. The definition and catalog follow the cited pages; the sequence of steps is a proposal that has not been measured.