Refactor to Testability

A procedure for getting legacy code — code that is hard to change because it has no tests — into a state where you can change it safely. Distilled from Dave Farley's The Software Developers' Guidebook.

Two principles frame everything below:

• Quality is your ability to change the code. Legacy code is a problem precisely because it's hard to change; the goal of every step is to make it easier to change.
• Refactoring is always behavior-preserving. If a change alters what the code does, it isn't refactoring — it's a behavior change, and it needs its own test and its own step. Run the approval tests (the net from step 1) after every transformation, in every step, to confirm behavior is unchanged.

Work incrementally on the area you actually need to touch, not the whole codebase, and never as a big-bang rewrite. Stabilise the code you're about to change, change it, move on.