codingrefactoring

Legacy Code Refactoring Plan

Analyses legacy code and produces a step-by-step refactoring plan with before/after examples and risk assessment.

Prompt

You are a senior engineer specialising in legacy code modernisation for [industry] applications. The goal is to improve maintainability without breaking existing functionality. The target audience for this plan is the development team. Analyse the following [language] code and create a step-by-step refactoring plan. Format the output as a structured numbered list. For each step, provide: (1) what to change and why, naming the code smell (e.g. 'God class', 'primitive obsession', 'shotgun surgery'), (2) the refactoring technique to apply (such as 'Extract Method', 'Replace Conditional with Polymorphism'), (3) before and after code snippets in a formatted code block, (4) risk level (low/medium/high) and what could break, (5) how to verify, with a specific test to write, for example 'assert that calculateTotal(items) returns the same value before and after the refactor'. You must order the steps from lowest risk to highest risk. Avoid suggesting a complete rewrite. Only work incrementally. Do not change the public API unless absolutely necessary. Only include 5-8 steps, each independently deployable. Mark any step that changes the public API. Here is the code:\n\n```[language]\n[PASTE CODE HERE]\n```

Why this prompt works

The most common bad refactoring suggestion is 'rewrite this entirely'. This prompt explicitly bans that ('Avoid suggesting a complete rewrite. Only work incrementally'), which forces the model to produce changes that can ship in small, reviewable chunks rather than a 6-month project. The risk-ordered step list (lowest to highest) is the discipline that lets you stop refactoring at any step and still have a working improvement. The 'how to verify' section per step (with the worked example of an assertion that should hold before and after) turns the plan from prose into something a team can actually validate.

When to reach for it

You're inheriting a code path that needs to change and want to refactor it before adding the new behaviour.
You're prepping a quarterly tech-debt sprint and need a structured plan rather than a list of files to delete.
You're scoping a refactor for stakeholders who need to see risk-versus-benefit per step.
You're learning refactoring techniques and want to see the named patterns applied to real code.

How to customise it

The industry context shapes which code smells the model prioritises. 'Healthcare' surfaces audit and traceability concerns; 'fintech' surfaces concurrency and data integrity. Be specific. The language affects the named techniques: 'Replace Conditional with Polymorphism' applies cleanly to OOP languages, less so to functional ones. For very large files (1,000+ lines), paste only the relevant section and tell the model the surrounding context separately; the prompt loses fidelity past a certain code length.

What good output looks like

A numbered list of 5 to 8 refactoring steps. Each step has the code smell named, the technique to apply, before and after code blocks, a risk level, what could break, and a verification test. Steps are ordered low risk to high risk. Public-API-changing steps are explicitly flagged. The plan is independently deployable step-by-step, so you can stop at any point and still have a working improvement. Total length depends on code size, typically 1,000 to 2,000 words.

refactoringlegacy codecode smellsclean codemodernisationChatGPT / Claude