Ett team ärver en faktureringsmodul som ingen helt förstår. Den har inga tester som skyddar befintligt beteende. En sprint föreslås för att "städa upp den", och planen är att skriva om kärnan i en ny struktur. Ingen kan säga hur de ska veta att den nya versionen fortfarande debiterar kunder korrekt.
Detta är ett illustrativt scenario, inte en dokumenterad incident. Det beskriver det gap som ett refaktoreringsutbildningsprojekt måste täcka: ingenjörer som kan se att koden är rörig, men ännu inte kan planera en begränsad förbättring och visa att beteendet bevarades.
Den här guiden är för chefer inom tekniska utvecklingsprojekt och tekniska chefer. Den behandlar hur man beskriver prestandaproblemet, diagnostiserar brister, förbereder och praktiserar designen, arbetar igenom ett fall och bedömer om färdigheten överförs till verkligt arbete. Den handlar om utbildningsdesign. Koden, testerna och reglerna i ditt program bör valideras av seniora ingenjörer på din egen stack.
Vad är ett refactoring-utbildningsprojekt?
Ett refaktoreringsutbildningsprojekt är ett strukturerat arbete med äldre kod, där syftet är att bygga upp kapacitet såväl som att förbättra koden. Deltagarna planerar en liten, begränsad förändring, skyddar befintligt beteende med tester, förbättrar designen i små steg och visar bevis på att ingenting är fel. Koden blir bättre, och, ännu viktigare, ingenjörerna övar det omdöme de behöver på verklig teknisk skuld.
Snabb fakta
| Fråga | Kort svar |
|---|---|
| Vad är uppgiften? | Planera och validera en begränsad förbättring av äldre kod. |
| Vad får du i poäng? | Riskanalys och bevis på att befintligt beteende bevarades. |
| Är en bred omskrivning ett bra utbildningsprojekt? | Vanligtvis inte. Det döljer den färdighet som övas och gör det svårt att visa bevarat beteende. |
| Räcker det med ett quiz om refaktoreringsmönster? | Nej. Det bekräftar förutsättningarna, men inte om en ingenjör kan planera och validera en ändring. |
| Vem validerar innehållet? | En teknisk chef och en senior ingenjör som känner till kodbasen. |
| Vad kan träning inte åtgärda? | Saknade testverktyg, utlösningstryck, oklart ägarskap och ingen tid för underhållsarbete. |
| Hur vet du att det fungerade? | Ett nytt, oset fall av äldre kod, poängsatt mot överenskomna kriterier, med uppföljning av verkligt arbete. |
1. Beskriv prestandaproblemet
Börja med uppgiften: planera och validera en begränsad förbättring av äldre kod. ”Begränsad” är det viktiga ordet. Eleven väljer en ändring som är tillräckligt liten för att slutföras, och kan ange vad som ligger inom och utanför ramen.
Det hjälper att vara precis med termer. Martin Fowler beskriver refactoring som en kontrollerad teknik för att förbättra designen av en befintlig kodbas, uppbyggd av små, beteendebevarande transformationer. Frasen "beteendebevarande" är det som skiljer refaktorering från en omskrivning, och det är vad utbildningen måste synliggöra. Själva metaforen om teknisk skuld myntades av Ward Cunningham, och Fowlers diskussion är en användbar påminnelse om att skulder kan tas på medvetet och klokt, så att inte varje rörig modul är ett misstag som måste åtgärdas.
Michael Feathers bok om äldre kod tar samma linje när det gäller praktik. Förlagets beskrivning säger att den lär utvecklare att skriva tester som säkerställer de ändrar inte oavsiktligt applikationenoch att få befintlig programvara under kontroll utan en fullständig omskrivning.
Skriv prestandadeklarationen i en mening och låt en teknisk chef granska den: ”Med tanke på en äldre modul och ett definierat mål föreslår ingenjören en begränsad förändring, lägger till tester som fastställer nuvarande beteende, gör förändringen i små steg och visar att beteendet bevaras.”
2. Diagnostisera inlärnings- och kontextuella luckor
Innan du bygger något, jämför den obligatoriska uppgiften med vad dina nuvarande aktiviteter övar och utvärderar. Tre frågor skiljer vanligtvis ett träningsgap från något annat:
- Använder nuvarande praxis den verkliga uppgiften? Om utbildningen täcker omstrukturering av mönster i bilder, men ingen någonsin ändrar otestad kod, har ingen övat på att skydda beteende. Om bedömning är ett flervalsvalsprov på kodlukt, mäter det återkallelse.
- Vad är det kognitiva kravet? I Blooms reviderade taxonomi sker bedömningen av huruvida en förändring är säker på analys- och utvärderingsnivåerna, och utformningen av planen och testerna når skapandenivån. Att matcha aktiviteter till dessa nivåer behandlas i vår guide till matcha läraktiviteter med Blooms taxonomi.
- Är det något annat än skicklighet som kommer i vägen? Kontrollera personal, verktyg och procedurer. Om bygget tar en timme kommer ingen att köra tester ofta. Om underhållsarbete aldrig schemaläggs kommer ingenjörer bara att omstrukturera i hemlighet. Rapportera orsaker som inte är utbildningsrelaterade till de personer som kan åtgärda dem.
3. Utforma målinriktad förberedelse och övning
När du väl vet vilka luckor träning kan täcka, ge varje steg en specifik uppgift.
Förberedelse. Kontrollera förkunskapskraven med en kort diagnostik: hur ert testramverk fungerar, vad ett karakteriseringstest är och hur ert team granskar och sammanfogar. Självstudier passar detta steg. En återkallelsekontroll bekräftar endast förkunskapskraven.
Öva. Använd systematiska refaktoreringsprojekt med en tydlig form. Börja med ett litet, säkert exempel och gå sedan vidare till en verklig men begränsad del av din egen kodbas. Gilded Rose-kata är en välkänd utgångspunkt för det första steget. Det är README, som underhålls av Emily Bache, rekommenderar att man skriver tester innan man ändrar koden och ramar in övningen som övning i att ta små steg, köra testerna ofta och förbättra designen bit för bit. En vettig sekvens för varje projekt är: definiera målet och avgränsningen, skriv tester som fångar vad koden gör idag, ändra en sak i taget, kör testerna efter varje steg och skriv ner vad du lärde dig.
Återkoppling. Koppla feedback till beslut, inte till en totalpoäng. ”Du extraherade rabattlogiken, men dina tester täckte bara den lyckliga vägen, så du kan inte ha märkt avrundningsförändringen” är mer användbart än ”3 av 5”.
Live input från läraren eller asynkron granskning? Live-input ger mest värde när ett val är tvetydigt, till exempel om man ska avbryta och lägga till ett saknat prov eller fortsätta. Asynkron repetition räcker när eleverna jämför sin plan och sina prov med en kommenterad expertversion. Många team använder båda: förberedelser i egen takt först, sedan en ledd session om de svåra fallen.
4. Arbeta igenom ett realistiskt exempel
Illustrativt. En teknisk chef bör validera fallet och svarskriterierna före användning.
Fallet. En äldre funktion beräknar en ordersumma, inklusive rabatt, moms och fraktregel. Den har inga tester. Ett team föreslår att omstrukturera hela faktureringsmodulen för att göra den "renare".
Uppgiften. Eleven förklarar vad de skulle göra, citerar de bevis de skulle samla in och anger vilken ytterligare information eller stöd de behöver.
Ett första försök. ”Jag skulle dela upp modulen i tre tjänster och flytta logiken, och sedan kontrollera siffrorna i staging.” Eleven har valt en stor förändring och en sen, manuell kontroll. Det finns inget sätt att avgöra om de gamla och nya versionerna överensstämmer om edge-fall.
Feedback och försök igen. Granskaren frågar vad funktionen gör idag för en tom varukorg, en rabatt som gör summan negativ och ett avrundningsfall. I det nya försöket ber man eleven att begränsa omfattningen till ett beteende och att säga hur de skulle bevisa att det inte förändrades.
Ett starkare försök. ”Jag skulle lämna modulstrukturen oförändrad för tillfället. Jag skulle registrera vad ordertotalfunktionen returnerar idag för en uppsättning indata, inklusive kantfallen, som tester. Sedan skulle jag extrahera rabattberäkningen till en egen funktion, köra testerna efter det enda steget och stoppa. Jag skulle notera att leveransregeln har ett beteende som jag inte förstår och fråga en kollega innan jag rör vid den.” Observera att detta svar begränsar förändringen, skyddar beteendet först och namnger det som är okänt.
Varför varje svar är försvarbart eller ofullständigt. Bedöm varje försök utifrån godkända kriterier, inte en granskares preferens. Det första försöket kan vara en förnuftig långsiktig riktning men är ofullständig som plan, eftersom det inte bär några bevis på bevarat beteende. Det starkare försöket är litet, kontrollerbart och ärligt om osäkerhet.
5. Bedöm kapacitet och planöverföring
Bevis på förmåga är prestation på ett nytt fall med äldre kod som eleven inte har sett. Poängsätt riskanalysen och bevisen på att beteendet bevarades. En enkel matris använder en skala från 0 till 2 per kriterium:
| Kriterium | Observerbara bevis |
|---|---|
| Uppgiftskörning | Planerar och validerar en begränsad förbättring av äldre kod och dokumenterar åtgärden och bevisen bakom den. |
| Resonemang | Förklarar begränsningarna, alternativen och osäkerheten, och kontrollerar riskerna och bevisen för att beteendet bevarades. |
| Gränser | Använder godkända rutiner och ber om hjälp när information eller befogenheter är otillräckliga. |
Ankare: 0 är frånvarande eller saknar stöd, 1 är partiell med relevanta utelämnanden och 2 är fullständig och motiverad mot överenskomna kriterier. Definiera kritiska fel separat, såsom att ändra beteende utan test som skulle ha märkt det, så att en övergripande poäng inte kan dölja ett. Denna bedömningsmatris är ett förslag, inte en validerad beredskapsstandard: anpassa den med en teknisk chef och testa den. Vår guide till utforma interaktiv praktik med användbar feedback visar hur man skriver feedback som kopplar till beslut.
Planera överföringen medvetet. Ge varje ingenjör en liten, reell skuld efter övningen att ta itu med med en granskare, eller gör en kort retrospektiv på en nyligen genomförd förändring som orsakade problem. Kontrollera överföringen efter lämplig erfarenhet av verkligt arbete, inte direkt efter workshopen.
Där interaktiv leverans hjälper
Interaktiva format hjälper till där alla bör engagera sig innan de träffar gruppen. I en livesession kan en handledare visa ett kort utdrag av den äldre versionen, be varje ingenjör att skicka in den första ändringen de skulle göra och hur de skulle bevisa att den är säker, och sedan avslöja spridningen före diskussionen. Samma prompt kan köras i egen takt för förberedelse. AhaSlides stöder interaktivt lärande och växling mellan live- och självstudier. Det är ett presentations- och inlärningsverktyg, inte en plats att köra eller analysera kod, så kör själva omstruktureringen i din egen miljö. Kontrollera eventuella specifika redigerings-, feedback- eller rapporteringsfunktioner som du planerar att förlita dig på mot ditt eget arbetsflöde. För vägledning om val av format, se vår artikel om när man ska använda adaptiv, interaktiv och liveinlärning.
Mät vad som förändrats
Bestäm i förväg vad som skulle visa att ingenjörer kan utföra uppgiften. Jämför kvaliteten på riskanalysen och bevisen på bevarat beteende i ett osedd fall mot en baslinje. Definiera vem som ingår, nämnaren och tidpunkten. Om resultaten förbättras, kontrollera vad som mer har förändrats under samma period, såsom nya testverktyg, en snabbare byggprocess eller ett ägarbyte, innan utbildningen tillgodoräknas.
Begränsningar som kan finnas kvar
- Dags för underhållsarbete. Om skuldarbete aldrig schemaläggs har utbildade ingenjörer fortfarande ingenstans att använda färdigheten.
- Testverktyg. Utan en användbar testsele eller en snabb byggnation är små steg och täta kontroller svåra att upprätthålla.
- Falltäckning. Ett äldre fall visar på några typer av risker. En poäng beskriver inte en ingenjörs bedömning i allmänhet.
- Bedömning av när man inte ska refaktorera. Viss kod är bättre att lämnas oförändrad, ersättas eller pensioneras, och det beslutet innebär mer än skicklighet.
- Överföra. Prestation i en kata är inte detsamma som prestation i en produktionsmodul under leveranspress.
Nämn dessa för sponsorer tidigt och planera separata åtgärder. Utbildning förbättrar vad en ingenjör kan planera och bevisa. Det skapar inte tid eller verktyg.
Vanliga frågor och svar
Vad är ett refactoring-utbildningsprojekt?
Det är strukturerad övning i äldre kod där ingenjörer planerar en liten förändring, skyddar befintligt beteende med tester, ändrar designen i små steg och visar att ingenting gick sönder.
Är en fullständig omskrivning ett bra sätt att lära sig om teknisk skuld?
Vanligtvis inte. En omskrivning är stor, svår att validera och döljer den färdighet du vill bygga upp. En begränsad förändring med tester som fångar aktuellt beteende synliggör resonemanget.
Hur bedömer du om ingenjörer kan refaktorera på ett säkert sätt?
Ge ett nytt fall med äldre kod och poängsätt riskanalysen och bevisen för att beteendet bevarades mot överenskomna kriterier. Ett quiz om refaktoreringsmönster bekräftar endast förutsättningarna.
Behöver du en exempelkodbas för utbildningen?
Du behöver någonstans att öva säkert. Många lag börjar med en offentlig kata och går sedan vidare till en avgränsad del av sin egen kod. Din tekniska chef bör bekräfta att koden är lämplig.
Var ska man börja
Välj en liten, återkommande typ av äldre förändring i din kodbas. Skriv prestandadeklarationen, låt en teknikchef validera fallet och de tester som skulle visa bevarat beteende, och utarbeta en matris med tre kriterier med en skala från 0 till 2 och en lista över kritiska fel. Pilotera det med en liten grupp innan du rullar ut det.
För att se hur en beslutsövning kring refaktorering kan köras live med ditt eget team och återanvändas i egen takt efteråt, utforska AhaSlides.
