Vissa klasser ”växer” inte. De sväller. Några sprintar senare äger en fil validering, persistens, API-anrop, formatering, loggning och halva dina affärsregler, och varje ”liten ändring” blir en skör, ångestframkallande redigering.
Den här refactor plan prompt är byggd för seniora utvecklare som städar upp legacy-moduler inför en riskfylld release, team leads som vill minska PR-churn och höja kvaliteten i kodgranskningar, och konsulter som gör en snabb designaudit för att ge kunder en realistisk refaktor-roadmap. Resultatet är en strukturerad nedbrytning av en uppblåst klass, en SOLID/SRP-diagnos och en steg-för-steg-refaktorplan med förslag på nya typer samt före/efter-snuttar.
Vad gör den här AI-prompten och när ska du använda den?
Vad den här prompten gör
När du ska använda den här prompten
Vad du får
Den inventerar fält och metoder, och grupperar sedan beteenden efter syfte (persistens, orkestrering, validering, domänlogik, I/O).
Den spårar kopplingar genom att peka ut beroenden som statiska anrop, direkt instansiering, ramverkstyper, globala variabler och service locators.
Den diagnosticerar SRP-brott och använder andra SOLID-principer bara när de stödjer en praktisk refaktorriktning.
Den föreslår konkreta seams och möjliga nya typer (klasser, gränssnitt, moduler) med tydliga ansvargränser.
Den tar fram en stegvis, testbar plan i stället för en ”rewrite”, inklusive vad du ska göra först och vad som kan vänta.
Du har en 600-raders ”Manager/Service/Helper”-klass som fortsätter att sluka orelaterade funktioner.
Bugfixar går långsamt eftersom varje ändring får oförutsägbara bieffekter över I/O, affärsregler och formatering.
Du ska precis lägga till ännu en integration och du ser att beroendegrafen blir allt fulare.
Kodgranskningar fastnar med kommentarer som ”den här klassen gör för mycket”, men ingen är överens om nästa steg.
Du behöver en refaktorplan som ryms i sprintar, inte en arkitektur-satsning på månen.
En ansvarskarta som grupperar metoder i 4–8 sammanhängande kluster med anteckningar om varför varje kluster finns.
En kopplingsrapport som listar inkommande/utgående samarbetspartners, bieffekter och de värsta syndarna att isolera först.
En prioriterad refaktorordning (oftast 6–12 steg) som du kan omvandla till tickets.
Föreslagna nya typer med namn, syfte och skisser på publika metoder för att göra extraheringen konkret.
Illustrativa före/efter-snuttar som visar hur anropsställen och beroenden förändras efter uppdelningen.
Hela AI-prompten: refaktorplan för uppblåst klass
Steg 1: Anpassa prompten med din information
Anpassa prompten
Fyll i fälten nedan för att anpassa prompten efter dina behov.
Variabel
Vad du ska ange
Anpassa prompten
[KLASSKOD]
Ange den fullständiga källkoden för klassen du vill analysera, inklusive alla egenskaper, metoder och beroenden.
Ange vilket programmeringsspråk som används i den angivna klasskoden. Det säkerställer att rekommendationerna följer språkets etablerade konventioner.
Till exempel: "Java"
[KONTEXT]
Ange relevant bakgrundsinformation om klassen, till exempel dess roll i systemet, beroenden samt eventuella designutmaningar eller mål.
Till exempel: "Klassen OrderProcessor är en del av en e-handelsplattform och hanterar betalningsbearbetning, ordervalidering och statusuppdateringar. Den samverkar med en PaymentGateway-tjänst och en databas för att spara orderdata."
Steg 2: Kopiera prompten
MÅL
🔒
PERSONA
🔒
BEGRÄNSNINGAR
🔒
PROCESS
🔒
Hantering av edge cases
🔒
INDATA
🔒
UTDATASPECIFIKATION
🔒
KVALITETSKONTROLLER
🔒
## MÅL
Hjälp en utvecklare att diagnosticera om en given klass försöker göra för mycket, och forma om den till en renare design genom att tillämpa SOLID (med fokus på single responsibility). Leveransen är en strukturerad genomgång av klassen plus handlingsbara refaktor-rekommendationer och illustrativa före/efter-snuttar.
## PERSONA
Agera som en forensisk analytiker inom mjukvarudesign med djup erfarenhet från enterprise. Du brukade leverera överdimensionerade, hårt kopplade komponenter och lärde dig den hårda vägen—nu närmar du dig klassdesign som en kliniker: identifiera symptom, spåra rotorsaker och ordinera små, testbara ansvarsområden.
## BEGRÄNSNINGAR
- Följ leveransstandarderna och sektionsordningen i **UTDATASPECIFIKATION**.
- Prioritera single responsibility, men referera till andra SOLID-principer när de stödjer refaktorplanen.
- Var specifik: namnge konkreta ansvarsområden, seams, beroenden och tänkbara nya typer (klasser/gränssnitt/moduler).
- Håll rekommendationerna realistiska för det givna språket och domänen.
- **Vad detta INTE är**
- Inte en fullständig omskrivning av hela systemet.
- Inte prestandajustering eller mikrooptimeringar om det inte är direkt orsakat av dåliga ansvarsområden.
- Inte en kritik av style guide eller formatering (om det inte döljer ansvarssgränser).
- Inte spekulativ arkitektur som inte är kopplad till den tillhandahållna klassen och kontexten.
## PROCESS
1. **Föranalys (visa förståelse först):** Återge kort vad du tror att användaren vill och vilka indata du har.
2. **Om det behövs, samla in saknad info:** Om koden eller kontexten saknas/är oklar, ställ riktade frågor och pausa.
3. **Inventera klassen:**
- Katalogisera properties/fält och vad varje verkar representera.
- Lista metoder och gruppera dem efter intention (t.ex. persistens, orkestrering, validering, UI, domänregler).
4. **Spåra kopplingar:**
- Identifiera beroenden (direkt instansiering, statiska anrop, service locators, globalt tillstånd, ramverkstyper).
- Kartlägg inkommande/utgående samarbeten och bieffekter (I/O, nätverk, DB, filsystem, UI).
5. **Extrahera domänbetydelsen:**
- Härled verklighetskonceptet och om klassnamnet matchar det konceptet.
- Identifiera klassens “anledning(ar) att ändras” och om det finns flera.
6. **Diagnostisera SRP-brott och SOLID-spänningar:**
- Peka ut blandade concerns (domän vs persistens, UI vs domän, policy vs mekanism, etc.).
- Notera sekundära SOLID-problem (OCP/DIP/ISP/LSP) endast när de påverkar lösningen påtagligt.
7. **Föreskriv refaktorer:**
- Föreslå en uppdelningsplan (nya typer, gränssnitt, gränser, ansvarsområden).
- Föreslå förbättringar av beroenderiktning (DIP), mindre gränssnitt (ISP) och utökningspunkter (OCP) där relevant.
8. **Demonstrera med kod:**
- Ge “före”-utdrag (minimala, representativa) och “efter”-exempel som visar den nya strukturen.
### Hantering av edge cases
- Om klassen är enorm, analysera de högst riskfyllda områdena först och fråga om du ska fortsätta med djupare genomgångar.
- Om språk-/ramverksbegränsningar hindrar vissa mönster, erbjud alternativ som passar ekosystemet.
- Om klassen redan är sammanhållen, förklara varför och föreslå mindre förbättringar i stället för att tvinga fram fragmentering.
## INDATA
- **Klasskod:** [KLASSKOD]
- **Programmeringsspråk:** [PROGRAMMERINGSSPRAK]
- **Applikations-/domänkontext:** [KONTEXT]
## UTDATASPECIFIKATION
Använd dessa rubriker i denna ordning och fyll varje med konkreta observationer:
1. **Uppgiftsförståelse**
- {Understanding Summary}
- {Assumptions Or Missing Inputs}
2. **Klassöversikt**
- {Inferred Purpose}
- {Primary Responsibilities Detected}
- {Red Flags At A Glance}
3. **Genomgång av tillstånd (fält/properties)**
- {Property Table} inklusive: namn, typ (om känd), vad det representerar, vilket ansvarsområde det stödjer, concerns/anteckningar
4. **Genomgång av beteende (metoder)**
- {Method Groups} (gruppera metoder efter intention)
- {Cohesion Notes} (vad som linjerar, vad som krockar)
5. **Samarbets- och beroendekarta**
- {External Dependencies}
- {Side Effects}
- {Coupling Hotspots}
6. **Domänkonceptets passform**
- {Modeled Concept Hypothesis}
- {Name Fit Assessment}
- {Alternative Naming Suggestions}
7. **Utvärdering av single responsibility**
- {Reasons To Change}
- {Specific SRP Violations} (punktlista, varje med evidens)
- {Impact On Testability & Maintainability}
8. **Refaktorplan (SOLID-anpassad)**
- {Target Design Overview}
- {Proposed Components} (t.ex. {New Class/Interface Name}: ansvarsområde, nyckelmetoder, beroenden)
- {Dependency Direction Changes} (hur DIP ska tillämpas, var abstraktioner ska injiceras)
- {Incremental Steps} (säker sekvens att implementera)
9. **Före/efter-kodillustrationer**
- {Before Snippet} (representativt utdrag)
- {After Snippet} (ny struktur)
- {Notes On Migration}
10. **Uppföljningsfrågor**
- {Questions To Confirm Constraints Or Next Steps}
## KVALITETSKONTROLLER
I slutet, inkludera en kort verifieringslista som bekräftar:
- {QC1} Klassens ansvarsområden var uttryckligen uppräknade och kopplade till evidens i koden.
- {QC2} Minst en tydlig analys av “anledning att ändras” gavs (och flera anledningar flaggades om de finns).
- {QC3} Rekommendationerna minskar koppling och förbättrar test-seams (nämn hur).
- {QC4} Refaktorstegen är inkrementella och genomförbara i [PROGRAMMERINGSSPRAK]/[KONTEXT].
- {QC5} Kodexempel demonstrerar ansvarssplitten i stället för att bara beskriva den.
Proffstips för bättre resultat med AI-prompten
Klistra in hela klassen, inte fragment. Ta med imports/usings, klass-signaturen och eventuella nästlade typer. Om den är för stor för ett meddelande, skicka den i två delar och lägg till: ”Del 1 av 2; vänta på del 2 innan du analyserar.”
Ge ett stycke kontext som namnger gränserna. Nämn var klassen ligger (API-lager, domän, UI) och vad den rör (DB, HTTP, kö). Ett enkelt tillägg som ”Det här ligger i vår ordertjänst; den pratar med Stripe och Postgres” förändrar rekommendationerna dramatiskt.
Be om en plan som är redo att bli tickets. Efter första outputen, följ upp med: ”Skriv om refaktorsekvensen som Jira-tickets med acceptanskriterier och uppskattad risk.” Då får du något du faktiskt kan schemalägga i stället för en generell designföreläsning.
Tvinga fram avvägningar genom att be om två spår. Testa: ”Ge en inkrementell plan (låg risk) och en modigare plan (högre payoff). Gör nu den inkrementella planen ännu säkrare genom att minska antalet flyttade metoder i steg 1.” Det håller prompten förankrad i riktiga sprintbegränsningar.
Använd dina tester som hävstång. Berätta hur testtäckningen ser ut och be sedan om en strategi: ”Våra tester är få; föreslå en outline för characterization tests innan extrahering.” Ärligt talat: extrahering utan skyddsnät är där refaktorer går för att dö.
Relaterade prompter
Om du paketerar din refaktorplan för intressenter hjälper de här prompterna dig att skärpa budskapet och presentera arbetet tydligt.
Om du också behöver omvandla dina tekniska fynd till vass internkommunikation är Revidera marknadstexter med den här AI-prompten användbar för att skriva om en ”vägg av text”-uppdatering från engineering till något din PM eller kund faktiskt läser. Använd den efter att du har skissat refaktorförslaget och vill göra det kortare, tydligare och mindre fullt av jargong.
För team som gör en bredare kvalitetspassning av dokumentationen runt förändringen (release notes, migrationsanteckningar, interna RFC:er) fungerar AI-prompt: granska din marknadsföringstext förvånansvärt bra som en strukturerad tydlighetsaudit. Klistra in din refaktorsammanfattning och be den flagga saknad kontext, vaga påståenden och ställen som behöver konkreta exempel.
När första auditen hittar problem och du vill ha en guidad omskrivningsplan kan Granska marknadstexter och åtgärda dem hjälpa dig iterera snabbare. Den är ett bra par när du försöker förklara varför SRP spelar roll i affärstermer och sedan direkt presenterar ”fixen” i ett lättsmält format.
Vilka roller har mest nytta av den här AI-prompten för refaktorplanering?
Seniora mjukvaruingenjörer använder den för att göra ”den här klassen är rörig” till en ansvarskarta och en säker extraheringssekvens. Tech leads lutar sig mot den för att samordna teamet kring gränser, ägarskap och en arbetsordning som passar sprintarbete. Mjukvaruarkitekter använder den för att hitta beroendeseams och avgöra var gränssnitt eller portar är rimliga utan att överarkitektera. Konsulter använder den för att ta fram en kundredo refaktor-roadmap med konkreta nya typer och före/efter-exempel.
Vilka branscher får mest värde av den här AI-prompten för refaktorplanering?
SaaS-bolag får värde eftersom produktkod ofta växer utifrån ”bara leverera”, och serviceklasser i det tysta samlar på sig fakturering, rättigheter/behörigheter och rapportering. Den här prompten hjälper till att dela upp ansvaret i testbara komponenter utan att spräcka releasetakten. Fintech-team gynnas när compliance-kontroller, auditloggning och betalningsintegrationer hamnar ihoptrasslade i en modul; outputen gör seamsen tydliga och enklare att isolera. E-handelsvarumärken har ofta order-, lager- och fulfillmentlogik blandad med tredjeparts-API-anrop; att extrahera adapters och domäntjänster minskar avbrott under högsäsong. Enterprise-IT-organisationer använder den för att modernisera legacy-kodbaser med mycket CRUD, där en enda klass rör databas, UI-formatering och orkestrering, vilket gör inkrementella refaktorer säkrare.
Varför ger grundläggande AI-prompter för refaktorplanering svaga resultat?
En typisk prompt som ”Refaktorera den här klassen så att den blir renare” misslyckas eftersom den: saknar en strukturerad inventering av fält och metoder, inte grupperar efter syfte (så SRP-brott förblir otydliga), ignorerar kopplingsdetaljer som statiska anrop och ramverksberoenden, ger generiska råd i stället för att namnge möjliga nya typer och seams, och missar en stegvis plan du kan genomföra säkert med tester. Den här prompten tvingar fram en explicit nedbrytning och gör sedan diagnosen till en realistisk sekvens av förflyttningar. Den ligger mycket närmare hur erfarna granskare faktiskt resonerar om ansvargränser.
Kan jag anpassa den här AI-prompten för refaktorplanering till min specifika situation?
Ja. Det snabbaste är att lägga till kontext före koden: språk/runtime, vilket lager klassen ligger i och vad ”säkert” betyder för dig (inga publika API-ändringar, minimal churn eller hårda deadlines). Du kan också säga vad du inte får ändra, som ”måste behålla den här ramverksbasklassen” eller ”kan inte ändra databasschemat den här kvartalen”. Efter första outputen kan du ställa en följdfråga som: ”Rangordna om refaktorstegen utifrån att vi bara kan röra 3 filer per sprint och vi behöver en quick win i steg 1.” Det tvingar planen att matcha dina begränsningar.
Vilka är de vanligaste misstagen när man använder den här refaktorplan-prompten?
Det största misstaget är att klistra in kod utan någon kontext om gränser; i stället för ”Här är en klass”, skriv ”Den här klassen ligger i API-lagret, anropar Postgres och en betalgateway och får inte ändra sina publika metoder den här månaden.” Ett annat vanligt fel är att utelämna samarbetspartners/beroenden, så prompten inte kan spåra kopplingar; ta åtminstone med gränssnitten den anropar eller en snabb lista över beroenden om du inte kan klistra in dem. Många ber också om en ”perfekt arkitektur”, vilket uppmuntrar till överuppdelning; be om ”små, testbara ansvar i 6–10 steg” för att hålla det förankrat. Till sist leder det till analysparalys att hoppa över frågan ”vad gör vi först”, så be uttryckligen om ett steg 1 som snabbt minskar risk.
Vem ska INTE använda den här AI-prompten för refaktorplanering?
Den här prompten är inte idealisk för engångsskript där långsiktig underhållbarhet inte spelar någon roll, eller för team som inte kan ändra kodstrukturen alls på grund av stela leverantörsbegränsningar. Den passar också dåligt om du letar efter mikrooptimeringar eller prestandatuning som inte beror på ihoptrasslade ansvar. Om du bara behöver snabb formateringsstädning, använd en linter/formatter och gå vidare. Den här är för designklarhet och säker extrahering.
Uppblåsta klasser gör inte bara att du jobbar långsammare; de döljer risk tills det är releasevecka. Klistra in din klass i promptvisaren, kör nedbrytningen och gå därifrån med en refaktorplan du faktiskt kan leverera.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.
