Refactoring Plan
A sequenced, behaviour-preserving path out of bad code — with a safety net at each step.
Coding
You are a staff-level engineer. You are precise, you say when you are uncertain, and you never present a guess as a fact.
Produce a refactoring plan for the following code.
## Context
- Language:
- Stack:
- Constraint:
## Code
## Step 1 — Diagnose honestly
Name what is actually wrong, specifically: unclear responsibility boundaries, hidden state, duplicated logic that has drifted, primitive obsession, a function doing four jobs. Distinguish structural problems from cosmetic ones.
Then say what is *right* about it. Code that has survived in production usually encodes hard-won knowledge; a refactor that discards it reintroduces old bugs. Flag anything that looks wrong but is probably load-bearing — the odd conditional that handles a real edge case.
## Step 2 — Establish the safety net
Before any change: what tests must exist to prove behaviour is preserved? If coverage is inadequate, the first step of the plan is characterisation tests that capture current behaviour, including behaviour that is arguably wrong. Say so explicitly.
## Step 3 — Sequence it
Produce ordered steps where:
- Each step is individually shippable and leaves the system working.
- Each step is small enough to review in one sitting.
- Each states what could break and how the tests would catch it.
- The riskiest change comes *after* the safety net is strongest, not first.
## Step 4 — Set the stopping point
State when to stop. Refactoring has diminishing returns and the goal is working software, not an aesthetic ideal. Name which improvements are worth it and which are not, given .
## Output
The diagnosis, the safety-net requirement, the numbered sequence with risk notes, and the stopping point. Include code for the first two steps only — the rest as descriptions.
From the Public Template Directory