Et team arver et faktureringsmodul, som ingen fuldt ud forstår. Det har ingen tests, der beskytter eksisterende adfærd. En sprint foreslås for at "rydde op i det", og planen er at omskrive kernen i en ny struktur. Ingen kan sige, hvordan de skal vide, at den nye version stadig opkræver korrekt betaling fra kunderne.
Dette er et illustrativt scenarie, ikke en dokumenteret hændelse. Det beskriver det hul, et refaktoreringstræningsprojekt skal lukke: ingeniører, der kan se, at koden er rodet, men endnu ikke kan planlægge en afgrænset forbedring og vise, at adfærden blev bevaret.
Denne vejledning er til tekniske supportledere og tekniske ledere. Den dækker, hvordan man beskriver performanceproblemet, diagnosticerer hullerne, forbereder designet og praktiserer det, arbejder med en case og vurderer, om færdighederne kan overføres til det virkelige arbejde. Den handler om træningsdesign. Koden, testene og reglerne i dit program bør valideres af erfarne ingeniører på din egen stak.
Hvad er et refactoring-træningsprojekt?
Et refactoring-træningsprojekt er et struktureret stykke arbejde med ældre kode, hvor formålet er at opbygge kapacitet såvel som at forbedre koden. Deltagerne planlægger en lille, afgrænset ændring, beskytter eksisterende adfærd med tests, forbedrer designet i små trin og viser bevis for, at intet er gået i stykker. Koden bliver bedre, og endnu vigtigere er det, at ingeniørerne øver den nødvendige dømmekraft på reel teknisk gæld.
hurtige fakta
| Spørgsmål | Kort svar |
|---|---|
| Hvad er opgaven? | Planlæg og valider en afgrænset forbedring af ældre kode. |
| Hvad scorer du? | Risikoanalyse og dokumentation for, at eksisterende adfærd blev bevaret. |
| Er en bred omskrivning et godt træningsprojekt? | Normalt ikke. Det skjuler den færdighed, der øves, og gør det svært at vise den bevarede adfærd. |
| Er en quiz om refactoringmønstre nok? | Nej. Det bekræfter forudsætninger, men ikke om en ingeniør kan planlægge og validere en ændring. |
| Hvem validerer indholdet? | En teknisk leder og en ledende ingeniør, der kender kodebasen. |
| Hvad kan træning ikke løse? | Manglende testværktøj, udløsningstryk, uklart ejerskab og ingen tid til vedligeholdelsesarbejde. |
| Hvordan ved du, at det virkede? | En ny, uset case-analyse af ældre kode, scoret ud fra aftalte kriterier, med opfølgning på faktisk arbejde. |
1. Beskriv ydeevneproblemet
Start med opgaven: planlæg og valider en afgrænset forbedring af ældre kode. "Afgrænset" er det vigtige ord. Den lærende vælger en ændring, der er lille nok til at blive færdig, og kan angive, hvad der er inden for og uden for omfanget.
Det hjælper at være præcis omkring termer. Martin Fowler beskriver refactoring som en kontrolleret teknik til forbedring af designet af en eksisterende kodebase, bestående af små, adfærdsbevarende transformationer. Udtrykket "adfærdsbevarende" er det, der adskiller refaktorering fra en omskrivning, og det er det, træningen skal synliggøre. Selve metaforen om teknisk gæld blev opfundet af Ward Cunningham, og Fowlers diskussion er en nyttig påmindelse om, at gæld kan optages bevidst og fornuftigt, så ikke alle rodede modul er en fejl, der skal rettes.
Michael Feathers' bog om ældre kode tager samme linje i praksis. Forlagets beskrivelse siger, at den lærer udviklere at skrive tests, der sikrer de ændrer ikke utilsigtet applikationenog at bringe eksisterende software under kontrol uden en fuldstændig omskrivning.
Skriv præstationserklæringen i én sætning, og få en teknisk leder til at kontrollere den: "Givet et ældre modul og et defineret mål foreslår ingeniøren en afgrænset ændring, tilføjer tests, der fastlægger den nuværende adfærd, foretager ændringen i små trin og viser, at adfærden bevares."
2. Diagnosticer lærings- og kontekstmanglerne
Før du bygger noget, skal du sammenligne den nødvendige opgave med det, du praktiserer i dine nuværende aktiviteter, og vurdere den. Tre spørgsmål adskiller normalt et træningsgab fra noget andet:
- Bruger nuværende praksis den virkelige opgave? Hvis træningen dækker refaktorering af mønstre i slides, men ingen nogensinde ændrer utestet kode, har ingen øvet sig i beskyttende adfærd. Hvis evaluering er en multiple-choice-test om kodelugt, måler den genkendelse.
- Hvad er den kognitive efterspørgsel? I Blooms reviderede taksonomi foregår vurderingen af, om en ændring er sikker, på analyse- og evalueringsniveauet, og design af planen og testene når skabelsesniveauet. Matchning af aktiviteter til disse niveauer er dækket i vores guide til Matching af læringsaktiviteter til Blooms taksonomi.
- Er der noget andet end færdigheder, der kommer i vejen? Tjek personale, værktøjer og procedurer. Hvis byggeriet tager en time, vil ingen køre tests ofte. Hvis vedligeholdelsesarbejde aldrig er planlagt, vil ingeniører kun refaktorere i hemmelighed. Rapportér ikke-oplæringsmæssige årsager til de personer, der kan reparere dem.
3. Design målrettet forberedelse og øvelse
Når du ved, hvilke huller træning kan lukke, så giv hvert trin en specifik opgave.
Forberedelse. Tjek forudsætningerne med en kort diagnosticering: hvordan dit testrammeværk fungerer, hvad en karakteriseringstest er, og hvordan dit team gennemgår og fusionerer. Selvstudium er egnet til denne fase. En genkaldelseskontrol bekræfter kun forudsætningerne.
Øve sig. Brug systematiske refaktoreringsprojekter med en klar form. Start med en lille, sikker prøve, og flyt derefter til en reel, men afgrænset del af din egen kodebase. Gilded Rose-kataen er et velkendt udgangspunkt for det første trin. Dens README, vedligeholdt af Emily Bache, anbefaler at skrive tests før kodeændringer og indrammer øvelsen som øvelse i at tage små skridt, køre testene ofte og forbedre designet lidt efter lidt. En fornuftig rækkefølge for hvert projekt er: definer målet og grænsen, skriv tests, der indfanger, hvad koden gør i dag, ændr én ting ad gangen, kør testene efter hvert trin, og skriv ned, hvad du har lært.
Feedback. Forbind feedback med beslutninger, ikke med en samlet score. "Du udtrak rabatlogikken, men dine tests dækkede kun den lykkelige vej, så du kunne ikke have bemærket afrundingsændringen" er mere nyttigt end "3 ud af 5".
Live instruktørinput eller asynkron gennemgang? Live input tilføjer mest værdi, når et valg er tvetydigt, for eksempel om man skal stoppe og tilføje en manglende test eller fortsætte. Asynkron gennemgang er tilstrækkelig, når eleverne sammenligner deres plan og tests med en kommenteret ekspertversion. Mange teams bruger begge dele: forberedelse i eget tempo først, derefter en faciliteret session om de svære cases.
4. Arbejd dig igennem et realistisk eksempel
Illustrativt. En teknisk leder bør validere casen og svarkriterierne før brug.
Sagen. En ældre funktion beregner en ordretotal, inklusive rabat, moms og en forsendelsesregel. Den har ingen tests. Et team foreslår at omstrukturere hele faktureringsmodulet for at gøre det "renere".
Opgaven. Den studerende forklarer, hvad de ville gøre, citerer den dokumentation, de ville indsamle, og siger, hvilke yderligere oplysninger eller støtte de har brug for.
Et første forsøg. "Jeg ville opdele modulet i tre tjenester og flytte logikken over, og derefter kontrollere tallene i staging." Den lærende har valgt en stor ændring og en sen, manuel kontrol. Der er ingen måde at afgøre, om den gamle og den nye version stemmer overens om edge cases.
Feedback og forsøg igen. Anmelderen spørger, hvad funktionen gør i dag for en tom kurv, en rabat, der gør summen negativ, og et afrundingstilfælde. I genforsøget bedes eleven om at indsnævre omfanget til én adfærd og fortælle, hvordan de ville bevise, at den ikke ændrede sig.
Et stærkere forsøg. "Jeg ville lade modulstrukturen være for nu. Jeg ville registrere, hvad ordretotalfunktionen returnerer i dag for et sæt input, inklusive kanttilfældene, som test. Derefter ville jeg udtrække rabatberegningen til sin egen funktion, køre testene efter det ene trin og stoppe. Jeg ville bemærke, at forsendelsesreglen har en adfærd, jeg ikke forstår, og spørge en kollega, før jeg rører ved den." Bemærk, at dette svar begrænser ændringen, beskytter adfærden først og navngiver det, der er ukendt.
Hvorfor hvert svar er forsvarligt eller ufuldstændigt. Bedøm hver enkelt ud fra godkendte kriterier, ikke en anmelders præference. Det første forsøg kan være en fornuftig langsigtet retning, men er ufuldstændig som plan, fordi den ikke indeholder tegn på bevaret adfærd. Det stærkere forsøg er lille, kontrollerbart og ærligt omkring usikkerhed.
5. Vurder kapacitet og planoverførsel
Bevis for evne er præstation på en ny case med ældre kode, som den lærende ikke har set. Giv point for risikoanalysen og beviset for, at adfærden blev bevaret. En simpel rubrik bruger en skala fra 0 til 2 pr. kriterium:
| Kriterium | Observerbare beviser |
|---|---|
| Opgaveudførelse | Planlægger og validerer en afgrænset forbedring af ældre kode og registrerer handlingen og beviserne bag den. |
| Ræsonnement | Forklarer begrænsningerne, alternativerne og usikkerheden, og kontrollerer risiciene og beviserne for, at adfærden blev bevaret. |
| Grænser | Anvender godkendte procedurer og beder om hjælp, når information eller autoritet er utilstrækkelig. |
Ankre: 0 er fraværende eller ikke understøttet, 1 er delvis med relevante udeladelser, og 2 er fuldstændig og begrundet i forhold til aftalte kriterier. Definer kritiske fejl separat, såsom ændring af adfærd uden test, der ville have bemærket det, så en samlet score ikke kan skjule en. Denne rubrik er et forslag, ikke en valideret parathedsstandard: tilpas den med en teknisk leder og afprøv den. Vores guide til design af interaktiv praksis med nyttig feedback viser, hvordan man skriver feedback, der knytter sig til beslutninger.
Planlæg overførslen bevidst. Giv hver ingeniør efter øvelsen en lille, reel gæld, som de skal tage op med en korrekturlæser, eller lav en kort retrospektiv på en nylig ændring, der ødelagde noget. Kontroller overførslen efter passende erfaring med rigtigt arbejde, ikke lige efter workshoppen.
Hvor interaktiv levering hjælper
Interaktive formater hjælper, hvor alle bør forpligte sig, før de ser gruppen. I en live-session kan en facilitator vise et kort uddrag af den ældre version, bede hver ingeniør om at indsende den første ændring, de ville foretage, og hvordan de ville bevise, at den er sikker, og derefter afsløre spredningen før diskussionen. Den samme prompt kan køres i eget tempo til forberedelse. AhaSlides understøtter interaktiv læring og skift mellem live og selvstændig levering. Det er et præsentations- og læringsværktøj, ikke et sted at køre eller analysere kode, så kør selve refactoringen i dit eget miljø. Tjek enhver specifik forfatter-, feedback- eller rapporteringsfunktion, du planlægger at stole på, i forhold til din egen arbejdsgang. For vejledning i valg af formater, se vores artikel om Hvornår skal man bruge adaptiv, interaktiv og live læring.
Mål hvad der har ændret sig
Beslut på forhånd, hvad der viser, at ingeniører kan udføre opgaven. Sammenlign kvaliteten af risikoanalysen og beviserne for bevaret adfærd i en uset case med en baseline. Definer, hvem der er inkluderet, nævneren og timingen. Hvis resultaterne forbedres, skal du kontrollere, hvad der ellers har ændret sig i samme periode, såsom nye testværktøjer, en hurtigere opbygning eller et ejerskifte, før du krediterer træningen.
Begrænsninger, der kan forblive
- Tid til vedligeholdelsesarbejde. Hvis gældsarbejde aldrig bliver planlagt, har uddannede ingeniører stadig ingen steder at bruge færdigheden.
- Testværktøj. Uden et brugbart testsele eller en hurtig konstruktion er små trin og hyppige kontroller svære at opretholde.
- Sagsdækning. Én ældre sag viser et par typer risici. En score beskriver ikke en ingeniørs vurdering generelt.
- Vurdering af, hvornår man ikke skal refaktorere. Noget kode er bedre at lade være, erstatte eller trække tilbage, og den beslutning involverer mere end færdigheder.
- Overførsel. Præstation i en kata er ikke det samme som præstation i et produktionsmodul under leveringspres.
Nævn disse for sponsorer tidligt og planlæg separate løsninger. Træning forbedrer, hvad en ingeniør kan planlægge og bevise. Det skaber ikke tiden eller værktøjerne.
Ofte stillede spørgsmål
Hvad er et refactoring-træningsprojekt?
Det er struktureret praksis på ældre kode, hvor ingeniører planlægger en lille ændring, beskytter eksisterende adfærd med tests, ændrer designet i små trin og viser, at intet gik i stykker.
Er en fuldstændig omskrivning en god måde at lære om teknisk gæld på?
Normalt ikke. En omskrivning er stor, svær at validere og skjuler den færdighed, du ønsker at opbygge. En afgrænset ændring med tests, der indfanger den nuværende adfærd, gør ræsonnementet synlig.
Hvordan vurderer du, om ingeniører kan refaktorere sikkert?
Giv et nyt tilfælde af ældre kode, og giv point for risikoanalysen og beviserne for, at adfærden blev bevaret i forhold til aftalte kriterier. En quiz om refaktoreringsmønstre bekræfter kun forudsætningerne.
Har du brug for en eksempelkodebase til træningen?
Du har brug for et sikkert sted at øve dig. Mange hold starter med en offentlig kata og går derefter videre til en afgrænset del af deres egen kode. Din tekniske leder bør bekræfte, at koden er passende.
Hvor skal man begynde
Vælg én lille, tilbagevendende type ældre ændring i din kodebase. Skriv performance statement, få en engineering manager til at validere casen og de tests, der viser bevaret adfærd, og udarbejd en rubrik med tre kriterier med en skala fra 0 til 2 og en liste over kritiske fejl. Afprøv det med en lille gruppe, før du ruller det ud.
For at se, hvordan en refaktoreringsbeslutningsøvelse kan køre live med dit eget team og genbruges i dit eget tempo bagefter, kan du udforske AhaSlides.
