Et team arver en faktureringsmodul som ingen forstår fullt ut. Den har ingen tester som beskytter eksisterende atferd. En sprint foreslås for å «rydde opp i den», og planen er å omskrive kjernen i en ny struktur. Ingen kan si hvordan de skal vite at den nye versjonen fortsatt belaster kundene riktig.
Dette er et illustrerende scenario, ikke en dokumentert hendelse. Det beskriver gapet et refaktoreringsopplæringsprosjekt må tette: ingeniører som kan se at koden er rotete, men som ennå ikke kan planlegge en avgrenset forbedring og vise at atferden ble bevart.
Denne veiledningen er for ledere innen ingeniørstøtte og ingeniørledere. Den dekker hvordan man beskriver ytelsesproblemet, diagnostiserer manglene, forbereder og praktiserer design, jobber seg gjennom en case og vurderer om ferdighetene kan overføres til faktisk arbeid. Den handler om opplæring i design. Koden, testene og reglene i programmet ditt bør valideres av senioringeniører på din egen stakk.
Hva er et refaktoreringsopplæringsprosjekt?
Et refaktoreringsopplæringsprosjekt er et strukturert arbeid med eldre kode, der formålet er å bygge kapasitet så vel som å forbedre koden. Deltakerne planlegger en liten, avgrenset endring, beskytter eksisterende atferd med tester, forbedrer designet i små trinn og viser bevis på at ingenting har vært ødelagt. Koden blir bedre, og enda viktigere, ingeniørene øver på den dømmekraften de trenger på reell teknisk gjeld.
Kjappe fakta
| Spørsmål | Kort svar |
|---|---|
| Hva er oppgaven? | Planlegg og valider en forbedring av avgrenset eldre kode. |
| Hva scorer du? | Risikoanalyse og bevis på at eksisterende atferd ble bevart. |
| Er en bred omskriving et godt opplæringsprosjekt? | Vanligvis ikke. Det skjuler ferdigheten som øves inn og gjør det vanskelig å vise frem bevart atferd. |
| Er en quiz om refaktoreringsmønstre nok? | Nei. Det bekrefter forutsetninger, men ikke om en ingeniør kan planlegge og validere en endring. |
| Hvem validerer innholdet? | En ingeniørsjef og en senioringeniør som kjenner kodebasen. |
| Hva kan trening ikke fikse? | Manglende testverktøy, utløsningstrykk, uklart eierskap og ingen tid til vedlikeholdsarbeid. |
| Hvordan vet du at det fungerte? | En ny, usett sak om eldre kode, scoret mot avtalte kriterier, med oppfølging av reelt arbeid. |
1. Beskriv ytelsesproblemet
Start med oppgaven: planlegg og valider en avgrenset forbedring av eldre kode. «Avgrenset» er det viktige ordet. Læreren velger en endring som er liten nok til å fullføres, og kan si hva som er innenfor og utenfor omfanget.
Det hjelper å være presis med begreper. Martin Fowler beskriver refaktorering som en kontrollert teknikk for å forbedre designet til en eksisterende kodebase, bygd opp av små, atferdsbevarende transformasjoner. Uttrykket «atferdsbevarende» er det som skiller refaktorering fra omskriving, og det er det opplæringen må synliggjøre. Selve metaforen om teknisk gjeld ble skapt av Ward Cunningham, og Fowlers diskusjon er en nyttig påminnelse om at gjeld kan tas opp bevisst og klokt, så ikke alle rotete moduler er en feil som må fikses.
Michael Feathers' bok om eldre kode tar samme linje når det gjelder praksis. Forlagets beskrivelse sier at den lærer utviklere å skrive tester som sikrer de endrer ikke applikasjonen utilsiktet, og å få kontroll over eksisterende programvare uten en fullstendig omskriving.
Skriv ytelseserklæringen i én setning og få en ingeniørsjef til å sjekke den: «Gitt en eldre modul og et definert mål, foreslår ingeniøren en avgrenset endring, legger til tester som fastslår nåværende atferd, gjør endringen i små trinn og viser at atferden bevares.»
2. Diagnostiser lærings- og konteksthullene
Før du bygger noe som helst, bør du sammenligne den nødvendige oppgaven med det du praktiserer i dine nåværende aktiviteter og vurderer. Tre spørsmål skiller vanligvis et opplæringsgap fra noe annet:
- Bruker dagens praksis den virkelige oppgaven? Hvis opplæringen dekker refaktoreringsmønstre i lysbilder, men ingen noen gang endrer uprøvd kode, har ingen øvd på beskyttende atferd. Hvis vurdering er en flervalgstest på kodelukt, måler den gjenkjenning.
- Hva er den kognitive etterspørselen? I Blooms reviderte taksonomi skjer vurderingen av om en endring er trygg på analyse- og evalueringsnivåene, og utformingen av planen og testene når opprettelsesnivået. Å matche aktiviteter til disse nivåene dekkes i vår veiledning til matche læringsaktiviteter med Blooms taksonomi.
- Er det noe annet enn ferdigheter som kommer i veien? Sjekk bemanning, verktøy og prosedyrer. Hvis byggingen tar en time, vil ingen kjøre tester ofte. Hvis vedlikeholdsarbeid aldri planlegges, vil ingeniører bare refaktorere i hemmelighet. Rapporter årsaker som ikke er relatert til opplæring til de som kan fikse dem.
3. Utform målrettet forberedelse og øvelse
Når du vet hvilke hull trening kan tette, gi hvert trinn en distinkt oppgave.
Forberedelse. Sjekk forkunnskapene med en kort diagnostikk: hvordan testrammeverket ditt fungerer, hva en karakteriseringstest er, og hvordan teamet ditt gjennomgår og slår sammen. Selvstudium passer for denne fasen. En gjentakelsessjekk bekrefter kun forkunnskapene.
Øve på. Bruk systematiske refaktoreringsprosjekter med en tydelig form. Start med et lite, sikkert utvalg, og flytt deretter til en reell, men avgrenset del av din egen kodebase. Gilded Rose-kataen er et velkjent utgangspunkt for det første trinnet. Det er README, vedlikeholdt av Emily Bache, anbefaler å skrive tester før man endrer koden og rammer inn øvelsen som øvelse i å ta små steg, kjøre testene ofte og forbedre designet litt etter litt. En fornuftig rekkefølge for hvert prosjekt er: definer målet og grensen, skriv tester som fanger opp hva koden gjør i dag, endre én ting om gangen, kjør testene etter hvert trinn og skriv ned hva du lærte.
Feedback. Knytt tilbakemeldinger til beslutninger, ikke til en totalpoengsum. «Du hentet ut rabattlogikken, men testene dine dekket bare den lykkelige veien, så du kan ikke ha lagt merke til avrundingsendringen» er mer nyttig enn «3 av 5».
Live instruktørinnspill eller asynkron gjennomgang? Live input gir mest verdi når et valg er tvetydig, for eksempel om man skal stoppe og legge til en manglende test eller fortsette. Asynkron gjennomgang er nok når elevene sammenligner planen og testene sine med en kommentert ekspertversjon. Mange team bruker begge deler: forberedelse i eget tempo først, deretter en tilrettelagt økt om de vanskelige tilfellene.
4. Arbeid deg gjennom et realistisk eksempel
Illustrativt. En ingeniørsjef bør validere tilfellet og svarkriteriene før bruk.
Saken. En eldre funksjon beregner en totalsum for bestillingen, inkludert rabatt, moms og fraktregel. Den har ingen tester. Et team foreslår å omstrukturere hele faktureringsmodulen for å gjøre den «renere».
Oppgaven. Eleven forklarer hva de ville gjort, siterer bevisene de ville samlet inn, og sier hvilken ytterligere informasjon eller støtte de trenger.
Et første forsøk. «Jeg ville delt modulen inn i tre tjenester og flyttet logikken over, og deretter sjekket tallene i oppsamlingen.» Læreren har valgt en stor endring og en sen, manuell sjekk. Det er ingen måte å si om den gamle og den nye versjonen stemmer overens om kanttilfeller.
Tilbakemelding og prøv på nytt. Kontrolløren spør hva funksjonen gjør i dag for en tom handlekurv, en rabatt som gjør totalen negativ, og et avrundingstilfelle. Det nye forsøket ber eleven om å begrense omfanget til én atferd og si hvordan de ville bevise at den ikke endret seg.
Et sterkere forsøk. «Jeg ville la modulstrukturen være i fred foreløpig. Jeg ville fanget opp det ordretotalfunksjonen returnerer i dag for et sett med input, inkludert kanttilfellene, som tester. Deretter ville jeg hentet ut rabattberegningen til sin egen funksjon, kjørt testene etter det ene trinnet og stoppet. Jeg ville lagt merke til at fraktregelen har en atferd jeg ikke forstår og spurt en kollega før jeg berører den.» Legg merke til at dette svaret begrenser endringen, beskytter atferden først og navngir det som er ukjent.
Hvorfor hvert svar er forsvarlig eller ufullstendig. Bedøm hver av dem mot godkjente kriterier, ikke en anmelders preferanse. Det første forsøket kan være en fornuftig langsiktig retning, men er ufullstendig som plan, fordi det ikke bærer noen bevis for bevart atferd. Det sterkeste forsøket er lite, kontrollerbart og ærlig om usikkerhet.
5. Vurder kapasitet og planoverføring
Bevis på evne er ytelse på et nytt tilfelle med eldre kode som eleven ikke har sett. Gi poeng til risikoanalysen og beviset på at atferden ble bevart. En enkel rubrikk bruker en skala fra 0 til 2 per kriterium:
| Criterion | Observerbare bevis |
|---|---|
| Oppgaveutførelse | Planlegger og validerer en avgrenset forbedring av eldre kode, og registrerer handlingen og bevisene bak den. |
| Argumentasjon | Forklarer begrensningene, alternativene og usikkerheten, og sjekker risikoene og bevisene for at atferden ble bevart. |
| Grenser | Bruker godkjente prosedyrer og ber om hjelp når informasjon eller myndighet er utilstrekkelig. |
Ankerpunkter: 0 er fraværende eller ikke støttet, 1 er delvis med relevante utelatelser, og 2 er fullstendig og begrunnet mot avtalte kriterier. Definer kritiske feil separat, for eksempel endret atferd uten test som ville ha lagt merke til det, slik at en samlet poengsum ikke kan skjule en. Denne rubrikken er et forslag, ikke en validert beredskapsstandard: tilpass den med en ingeniørleder og test den. Vår veiledning til utforme interaktiv praksis med nyttig tilbakemelding viser hvordan man skriver tilbakemeldinger som er knyttet til beslutninger.
Planlegg overføringen bevisst. Etter øvelsen, gi hver ingeniør en liten, reell gjeldspost som de skal ta opp med en kontrollør, eller kjør en kort tilbakeblikk på en nylig endring som ødela noe. Sjekk overføringen etter passende erfaring med reelt arbeid, ikke rett etter workshopen.
Der interaktiv levering hjelper
Interaktive formater hjelper der alle bør forplikte seg før de ser gruppen. I en live-sesjon kan en tilrettelegger vise et kort utdrag fra den eldre teksten, be hver ingeniør om å sende inn den første endringen de ville gjort og hvordan de ville bevise at den var trygg, og deretter avsløre spredningen før diskusjonen. Den samme oppgaven kan kjøres i eget tempo for forberedelse. AhaSlides støtter interaktiv læring og veksling mellom live og selvstendig levering. Det er et presentasjons- og læringsverktøy, ikke et sted å kjøre eller analysere kode, så kjør selve refaktoreringen i ditt eget miljø. Sjekk eventuelle spesifikke redigerings-, tilbakemeldings- eller rapporteringsfunksjoner du planlegger å stole på mot din egen arbeidsflyt. For veiledning om valg av formater, se artikkelen vår om når man skal bruke adaptiv, interaktiv og live læring.
Mål hva som endret seg
Bestem på forhånd hva som vil vise at ingeniører kan utføre oppgaven. Sammenlign kvaliteten på risikoanalysen og bevisene på bevart atferd i et usett tilfelle, mot en grunnlinje. Definer hvem som er inkludert, nevneren og tidspunktet. Hvis resultatene forbedres, sjekk hva annet som endret seg i samme periode, for eksempel nytt testverktøy, raskere bygging eller eierskifte, før du godskriver opplæringen.
Begrensninger som kan gjenstå
- Tid for vedlikeholdsarbeid. Hvis gjeldsarbeid aldri blir planlagt, har trente ingeniører fortsatt ingen steder å bruke ferdighetene.
- Testverktøy. Uten en brukbar testsele eller en rask konstruksjon er små skritt og hyppige kontroller vanskelig å opprettholde.
- Saksdekning. Ett eldre tilfelle viser noen typer risiko. En poengsum beskriver ikke en ingeniørs vurderingsevne generelt.
- Å vurdere når man ikke skal refaktorere. Noe kode bør man la være å bruke, erstatte eller pensjonere, og den avgjørelsen innebærer mer enn bare ferdigheter.
- Overføre. Ytelse i en kata er ikke det samme som ytelse i en produksjonsmodul under leveringspress.
Gi sponsorene beskjed tidlig og planlegg separate løsninger. Opplæring forbedrer hva en ingeniør kan planlegge og bevise. Det skaper ikke tiden eller verktøyet.
Ofte stilte spørsmål
Hva er et refaktoreringsopplæringsprosjekt?
Det er strukturert praksis på eldre kode der ingeniører planlegger en liten endring, beskytter eksisterende atferd med tester, endrer designet i små trinn og viser at ingenting gikk i stykker.
Er en fullstendig omskriving en god måte å lære om teknisk gjeld på?
Vanligvis ikke. En omskriving er stor, vanskelig å validere og skjuler ferdigheten du ønsker å bygge. En avgrenset endring med tester som fanger opp gjeldende atferd gjør resonnementet synlig.
Hvordan vurderer du om ingeniører kan refaktorere på en sikker måte?
Gi et nytt tilfelle av eldre kode og gi poeng til risikoanalysen og bevisene for at atferden ble bevart i henhold til avtalte kriterier. En quiz om refaktoreringsmønstre bekrefter kun forutsetningene.
Trenger du en eksempelkodebase for opplæringen?
Du trenger et sted å øve trygt. Mange lag starter med en offentlig kata og går deretter videre til en avgrenset del av sin egen kode. Din tekniske leder bør bekrefte at koden er passende.
Hvor skal jeg starte
Velg én liten, tilbakevendende type eldre endring i kodebasen din. Skriv ytelseserklæringen, få en ingeniørsjef til å validere tilfellet og testene som viser bevart oppførsel, og utarbeid en rubrikk med tre kriterier med en skala fra 0 til 2 og en liste over kritiske feil. Test det med en liten gruppe før du ruller det ut.
For å se hvordan en refaktoreringsbeslutningsøvelse kan kjøres live med ditt eget team, og brukes om igjen i ditt eget tempo etterpå, kan du utforske AhaSlides.
