Der Code-Refactoring-Berater: Vorher-Nachher-Korrekturen mit einem Risikoscore für jede
Why this prompt matters
Developers now spend 23-42% of their work week dealing with technical debt and bad code — the Stripe Developer Coefficient study puts the global cost at $85 billion in lost productivity a year. The failure mode isn't not knowing code is bad; it's not knowing which fix is safe to make first. A one-standard-deviation rise in an organization's debt-to-code ratio corresponds to a 31% jump in defect density — refactoring the wrong part first, or all of it at once, is how technical debt cleanup itself introduces new bugs.
What we use it for
You've inherited a 400-line function that everyone on the team avoids touching because it 'works, mostly' and nobody remembers why it's structured the way it is. You need to clean it up before adding a new feature, but you don't have time to rewrite it from scratch and can't afford to break the parts that work.
Prompt
You are a senior software engineer with expertise in refactoring legacy code without introducing regressions. You are conservative by default — you flag risk honestly rather than being falsely reassuring. CONTEXT: Language/framework: [YOUR LANGUAGE, e.g. "TypeScript, Node.js, Express"] What this code does: [ONE-SENTENCE DESCRIPTION OF THE FUNCTION'S PURPOSE] Known problems (if any): [WHAT YOU ALREADY SUSPECT IS WRONG, e.g. "deeply nested conditionals, unclear variable names, does three unrelated things"] Test coverage: [DESCRIBE CURRENT TESTS, e.g. "one integration test covering the happy path only" or "none"] Constraints: [ANYTHING THAT CANNOT CHANGE, e.g. "the public function signature must stay identical, this is called from 40+ places"] TASK: Review the code below and identify 3-6 specific, independent refactoring opportunities. For EACH one: 1. Name the problem (e.g. "duplicated validation logic", "mixed abstraction levels", "unclear boolean flag parameter"). 2. Show the BEFORE code snippet (just the relevant lines, not the whole function). 3. Show the AFTER code snippet with the fix applied. 4. Assign a Risk Score (Low/Medium/High) based on: how much of the function's behavior the change touches, whether existing tests would catch a regression, and whether the change is purely structural (safe) or alters logic/behavior (riskier). 5. State what you'd want to verify manually or via a new test before merging this specific change. CONSTRAINTS: - Do NOT rewrite the entire function in one pass. Each refactor must be independently applicable — I need to be able to accept refactor #2 without necessarily taking #4. - Order your suggestions from LOWEST risk to HIGHEST risk, so I can bank easy wins first. - If the function is doing more than one job, say so explicitly and suggest a split — but still give me the low-risk internal cleanups first, since a full split is inherently higher-risk. - Do not suggest changes that alter the function's observable behavior unless you flag it as Medium or High risk with a clear explanation of what changes. - If test coverage is described as weak or absent, recommend which specific test(s) to write BEFORE attempting the Medium/High risk refactors, not after. OUTPUT FORMAT: ## Refactor 1: [Problem name] — Risk: [Low/Medium/High] **Before:** ``` [code] ``` **After:** ``` [code] ``` **Verify before merging:** [what to check or test] [repeat for each refactor, low to high risk] ## Summary [One paragraph: overall assessment of the function's health, and the recommended order of operations] CODE TO REVIEW: [PASTE YOUR FUNCTION OR CODE BLOCK HERE]
Result
Refactor 1: Duplicated validation logic — Risk: Low
Before:
if (!user.email || user.email.length === 0) { throw new Error('Email required'); }
if (!user.name || user.name.length === 0) { throw new Error('Name required'); }
if (!user.phone || user.phone.length === 0) { throw new Error('Phone required'); }After:
const requiredFields = ['email', 'name', 'phone'];
for (const field of requiredFields) {
if (!user[field]?.length) throw new Error(`${field} required`);
}Verify before merging: Confirm error message format isn't parsed elsewhere by exact string match — the field name capitalization changed slightly.
Refactor 2: Unclear boolean flag parameter — Risk: Low
Before:
function processOrder(order, flag) {
if (flag) { applyDiscount(order); }
...
}After:
function processOrder(order, { applyLoyaltyDiscount }) {
if (applyLoyaltyDiscount) { applyDiscount(order); }
...
}Verify before merging: Update all 6 call sites to pass a named object instead of a positional boolean — purely mechanical, no behavior change, but touches every caller.
Refactor 3: Deeply nested conditionals — Risk: Medium
Before:
if (user.active) {
if (user.subscription) {
if (user.subscription.tier === 'pro') {
// 15 more lines
}
}
}After:
if (!user.active) return;
if (!user.subscription) return;
if (user.subscription.tier !== 'pro') return;
// 15 more lines, now unindentedVerify before merging: Early returns change control flow if there's an else branch further down handling the negative case elsewhere in the original function — check for one before applying. Write a test for the non-pro-tier path specifically, since current coverage doesn't exercise it.
Refactor 4: Function does three unrelated things — Risk: High
Before: Single 400-line function handles validation, discount calculation, and email notification in sequence.
After: Split into validateOrder(), calculateDiscount(), and notifyCustomer(), called in sequence from a thin orchestrator function.
Verify before merging: This changes the function's shape enough that any code relying on partial execution (e.g. catching an error mid-function and still sending a notification) will behave differently. Do NOT attempt this split until Refactors 1-3 are merged and you have integration test coverage for all three code paths — this should be its own PR, reviewed separately.
Summary
This function is moderately unhealthy but not unsalvageable. Refactors 1-2 are safe, mechanical wins you can ship today. Refactor 3 needs one new test first but is still low-stakes. Refactor 4 (the actual split) is the real fix but should wait until the others are merged and stable — attempting all four at once is how a cleanup PR turns into a production incident.
Die meisten Refactoring-Prompts liefern eine einzige riesige Umschreibung Ihrer Funktion und hoffen, dass sie korrekt ist. Das ist für echten Produktionscode der falsche Ansatz – eine einzige umfassende Umschreibung ist genau die Art von Änderung, die am schwersten zu überprüfen, am schwersten zu testen und am wahrscheinlichsten eine Regression in einem Diff versteckt, der zu groß ist, als dass ihn jemand richtig prüfen könnte. Dieser Prompt macht das Gegenteil: Er zerlegt die Bereinigung in unabhängige, einzeln zusammenführbare Stücke und bewertet sie danach, wie viel sie kaputt machen könnten.
Warum die Risikobewertung vor der Code-Qualitätsbewertung kommt
Ein Refactoring, das die Lesbarkeit verbessert, aber kein beobachtbares Verhalten ändert, unterscheidet sich grundlegend von einem, das die tatsächliche Logik berührt, selbst wenn beide wie ähnlich große Diffs aussehen. Der Prompt erzwingt diese Unterscheidung, indem er einen Risikoscore basierend auf drei spezifischen Faktoren verlangt: wie stark die Änderung das Verhalten berührt, ob bestehende Tests eine Regression abfangen würden, und ob die Änderung rein strukturell ist oder die Logik verändert. Dies verwandelt ein vages Gefühl von "das fühlt sich riskant an" in eine wiederholbare Entscheidung, die das Modell begründen muss.
Warum Korrekturen mit geringem Risiko zuerst kommen
Vorschläge vom niedrigsten zum höchsten Risiko zu ordnen, ist nicht nur eine Frage der Sicherheit – es geht um Dynamik. Teams, die eine schlechte Funktion vermeiden, vermeiden sie oft ganz, einschließlich der Teile, die trivial sicher zu beheben sind. Zuerst ein paar Erfolge mit geringem Risiko zu erzielen (umbenannte Variablen, deduplizierte Validierung, ersetzte Boolean-Flags durch benannte Parameter) schafft Vertrauen und verkleinert die Datei, bevor jemand eine schwierigere Entscheidung über die riskanteren strukturellen Änderungen treffen muss.
Warum er vor riskanten Vorschlägen nach der Testabdeckung fragt
Die häufigste Art, wie Refactoring schiefgeht, ist, direkt zum befriedigenden Teil zu springen – eine aufgeblähte Funktion in saubere, gut benannte Teile aufzuteilen – ohne zu überprüfen, ob die aktuellen Tests die geänderten Codepfade tatsächlich abdecken. Dieser Prompt prüft explizit Ihre angegebene Testabdeckung und teilt Ihnen, falls sie schwach ist, mit, welchen Test Sie schreiben sollten, bevor Sie die riskanteren Refactorings versuchen, anstatt nachdem etwas in der Produktion kaputtgegangen ist.
Warum die Funktionsaufteilung als eigener PR gekennzeichnet wird
Eine Funktion mit mehreren Verantwortlichkeiten in separate Funktionen aufzuteilen, ist normalerweise die "echte" Korrektur, die alle wollen, aber es ist auch die Änderung, die am wahrscheinlichsten subtile Verhaltensweisen verändert – Fehlerbehandlungspfade, partielle Ausführungszustände, Nebenwirkungsreihenfolge. Der Prompt behandelt dies bewusst als separates, höher riskantes Refactoring, das erst durchgeführt werden sollte, nachdem die sichereren Bereinigungen zusammengeführt und stabil sind, anstatt es mit den einfachen Erfolgen in dieselbe Änderung zu packen.
Wie man es anpasst
Seien Sie konkret zu Ihren Einschränkungen – eine Funktion, die von 40 Stellen aufgerufen wird, verhält sich unter Refactoring-Druck ganz anders als eine, die von einer einzigen Testdatei aufgerufen wird. Wenn Sie tatsächlich keine Testabdeckung haben, erwarten Sie, dass das Modell empfiehlt, Tests zu schreiben, bevor Sie über die ersten ein oder zwei risikoreichen Punkte hinausgehen, und behandeln Sie diese Empfehlung als die eigentliche Antwort, nicht als Formalität, die übersprungen werden kann.