Een team erft een facturatiemodule die niemand volledig begrijpt. Er zijn geen tests die het bestaande gedrag beschermen. Er wordt een sprint voorgesteld om de module "op te schonen", en het plan is om de kern in een nieuwe structuur te herschrijven. Niemand kan garanderen dat de nieuwe versie de klanten nog steeds correct factureert.
Dit is een illustratief scenario, geen gedocumenteerd incident. Het beschrijft de kloof die een refactoring-trainingsproject moet overbruggen: engineers die wel zien dat de code rommelig is, maar nog geen concrete verbetering kunnen plannen en aantonen dat het gedrag behouden is gebleven.
Deze handleiding is bedoeld voor engineering enablement leads en engineering managers. Het behandelt hoe je een prestatieprobleem beschrijft, de knelpunten diagnosticeert, de voorbereiding en oefening ontwerpt, een casus doorneemt en beoordeelt of de vaardigheden in de praktijk toepasbaar zijn. Het gaat om het ontwerpen van trainingen. De code, tests en regels in je programma moeten worden gevalideerd door senior engineers op je eigen stack.
Wat is een refactoring-trainingsproject?
Een refactoring-trainingsproject is een gestructureerde oefening met bestaande code, waarbij het doel is om functionaliteit op te bouwen en de code te verbeteren. De deelnemers plannen een kleine, afgebakende wijziging, beschermen het bestaande gedrag met tests, verbeteren het ontwerp in kleine stappen en tonen aan dat er niets kapot is gegaan. De code wordt beter en, belangrijker nog, de engineers oefenen het beoordelingsvermogen dat ze nodig hebben bij het oplossen van echte technische schulden.
Faktenüberblick
| Vraag | Kort antwoord |
|---|---|
| Wat is de taak? | Plan en valideer een afgebakende verbetering van de bestaande code. |
| Wat is je score? | Risicoanalyse en bewijs dat bestaand gedrag behouden is gebleven. |
| Is een grootschalige herziening een goed trainingsproject? | Meestal niet. Het verbergt de vaardigheid die wordt geoefend en maakt het moeilijk om het aangeleerde gedrag te tonen. |
| Is een quiz over refactoringpatronen voldoende? | Nee. Het bevestigt de randvoorwaarden, maar niet of een ingenieur een wijziging kan plannen en valideren. |
| Wie valideert de inhoud? | Een engineeringmanager en een senior engineer die de codebase kent. |
| Wat kan training niet oplossen? | Ontbrekende testapparatuur, drukontlasting, onduidelijke verantwoordelijkheden en geen tijd voor onderhoudswerkzaamheden. |
| Hoe weet je dat het gelukt is? | Een nieuwe, onbekende casus met verouderde code, beoordeeld aan de hand van overeengekomen criteria, met vervolgonderzoek in de praktijk. |
1. Beschrijf het prestatieprobleem
Begin met de taak: plan en valideer een afgebakende verbetering van de bestaande code. "Afgebakend" is hier het sleutelwoord. De cursist kiest een wijziging die klein genoeg is om af te ronden en kan aangeven wat wel en niet binnen de scope valt.
Het is belangrijk om de terminologie nauwkeurig te definiëren. Martin Fowler beschrijft refactoring als een gecontroleerde techniek om het ontwerp van een bestaande codebase te verbeteren , bestaande uit kleine, gedragsbehoudende transformaties. De term "gedragsbehoudend" onderscheidt refactoring van een volledige herschrijving en is essentieel voor de training. De metafoor van technische schuld werd bedacht door Ward Cunningham , en Fowlers uitleg herinnert ons eraan dat schuld bewust en weloverwogen kan worden aangegaan, waardoor niet elke rommelige module een fout is die moet worden gecorrigeerd.
Het boek van Michael Feathers over legacy-code volgt dezelfde praktische benadering. Volgens de uitgever leert het ontwikkelaars tests te schrijven die ervoor zorgen dat ze de applicatie niet onbedoeld wijzigen , en bestaande software onder controle te houden zonder deze volledig opnieuw te hoeven schrijven.
Formuleer de prestatieomschrijving in één zin en laat deze door een engineeringmanager controleren: "Gegeven een bestaande module en een gedefinieerd doel, stelt de engineer een afgebakende wijziging voor, voegt tests toe die het huidige gedrag vastleggen, voert de wijziging stapsgewijs door en toont aan dat het gedrag behouden blijft."
2. Stel de leer- en contexthiaten vast.
Voordat je iets bouwt, vergelijk de vereiste taak met wat je momenteel oefent en evalueert. Drie vragen onderscheiden doorgaans een trainingsachterstand van iets anders:
- Wordt in de huidige praktijk gebruikgemaakt van de daadwerkelijke taak? Als de training refactoringpatronen in slides behandelt, maar niemand ooit ongeteste code aanpast, heeft niemand geoefend met het beschermen van gedrag. Als de beoordeling een meerkeuzetest over code smells is, meet deze het vermogen om code te onthouden.
- Wat is de cognitieve belasting? In de herziene taxonomie van Bloom valt het beoordelen of een verandering veilig is onder de niveaus 'analyseren' en 'evalueren', terwijl het ontwerpen van het plan en de tests onder het niveau 'creëren' valt. Het koppelen van activiteiten aan deze niveaus wordt besproken in onze handleiding. Leeractiviteiten afstemmen op de taxonomie van Bloom..
- Is er iets anders dan vaardigheid dat in de weg staat? Controleer de personeelsbezetting, de tools en de procedures. Als de build een uur duurt, zal niemand vaak tests uitvoeren. Als er nooit onderhoudswerkzaamheden worden ingepland, zullen engineers alleen in het geheim refactoren. Meld oorzaken die niet gerelateerd zijn aan training aan de mensen die ze kunnen oplossen.
3. Ontwerp doelgerichte voorbereiding en oefening
Zodra je weet welke lacunes door training kunnen worden opgevuld, geef je elke fase een specifieke taak.
Voorbereiding. Controleer de vereisten met een korte diagnose: hoe uw testframework werkt, wat een karakteriseringstest is en hoe uw team beoordelingen uitvoert en resultaten samenvoegt. Zelfstudie is geschikt voor deze fase. Een herhalingstoets bevestigt alleen de vereisten.
Oefening baart kunst. Gebruik systematische refactoringprojecten met een duidelijke structuur. Begin met een klein, veilig voorbeeld en ga vervolgens verder met een echt, maar afgebakend deel van je eigen codebase. De Gilded Rose kata is een bekend startpunt voor de eerste stap. De README, bijgehouden door Emily Bache, raadt aan om tests te schrijven voordat je de code wijzigt en presenteert de oefening als een oefening in het nemen van kleine stappen, het regelmatig uitvoeren van de tests en het beetje bij beetje verbeteren van het ontwerp. Een verstandige volgorde voor elk project is: definieer het doel en de grenzen, schrijf tests die vastleggen wat de code vandaag doet, wijzig één ding tegelijk, voer de tests na elke stap uit en schrijf op wat je hebt geleerd.
Feedback. Koppel feedback aan beslissingen, niet aan een totaalscore. "Je hebt de kortingslogica eruit gehaald, maar je tests hebben alleen het 'happy path' getest, dus je had de afrondingswijziging niet kunnen opmerken" is nuttiger dan "3 van de 5".
Live begeleiding door een docent of asynchroon nakijken? Live begeleiding is vooral waardevol wanneer er een onduidelijke keuze is, bijvoorbeeld of je moet stoppen en een ontbrekende toets moet toevoegen of door moet gaan. Asynchroon nakijken is voldoende wanneer leerlingen hun plan en toetsen vergelijken met een versie van een expert met aantekeningen. Veel teams gebruiken beide: eerst zelfstudie, gevolgd door een begeleide sessie over de lastige gevallen.
4. Werk een realistisch voorbeeld uit.
Ter illustratie. Een engineeringmanager dient de casus en de antwoordcriteria te valideren alvorens deze te gebruiken.
De casus. Een verouderde functie berekent het totaalbedrag van een bestelling, inclusief korting, btw en verzendkosten. Deze functie is niet getest. Een team stelt voor om de gehele facturatiemodule te herstructureren om deze "overzichtelijker" te maken.
De opdracht. De leerling legt uit wat hij/zij zou doen, noemt het bewijsmateriaal dat hij/zij zou verzamelen en geeft aan welke aanvullende informatie of ondersteuning hij/zij nodig heeft.
Een eerste poging. "Ik zou de module opsplitsen in drie services en de logica overzetten, en vervolgens de cijfers in de testomgeving controleren." De cursist heeft gekozen voor een grote wijziging en een late, handmatige controle. Er is geen manier om te controleren of de oude en nieuwe versies overeenkomen in de randgevallen.
Feedback en herkansing. De beoordelaar vraagt wat de functie momenteel doet bij een lege winkelwagen, een korting die het totaal negatief maakt en afrondingsfouten. Bij de herkansing wordt de cursist gevraagd zich te beperken tot één gedrag en uit te leggen hoe hij of zij zou bewijzen dat dit gedrag niet is veranderd.
Een krachtigere poging. "Ik zou de modulestructuur voorlopig ongewijzigd laten. Ik zou vastleggen wat de functie voor het totaalbedrag van de bestelling vandaag de dag retourneert voor een reeks invoerwaarden, inclusief de randgevallen, als tests. Vervolgens zou ik de kortingsberekening in een aparte functie onderbrengen, de tests na die ene stap uitvoeren en stoppen. Ik zou noteren dat de verzendregel gedrag vertoont dat ik niet begrijp en een collega raadplegen voordat ik er iets aan verander." Merk op dat dit antwoord de wijziging afbakent, eerst het gedrag beschermt en benoemt wat onbekend is.
Waarom elk antwoord verdedigbaar of onvolledig is. Beoordeel elk antwoord aan de hand van goedgekeurde criteria, niet aan de hand van de voorkeur van een beoordelaar. De eerste poging kan een verstandige richting voor de lange termijn zijn, maar is als plan onvolledig omdat er geen bewijs is van het behouden gedrag. De sterkere poging is klein, controleerbaar en eerlijk over de onzekerheid.
5. Beoordeel de capaciteit en plan de overdracht.
Bewijs van bekwaamheid wordt geleverd door de prestatie op een nieuwe, verouderde codecasus die de leerling nog niet eerder is tegengekomen. Beoordeel de risicoanalyse en het bewijs dat het gedrag is behouden. Een eenvoudige beoordelingsschaal gebruikt een score van 0 tot 2 per criterium:
| Criterium | Observeerbaar bewijs |
|---|---|
| Taakuitvoering | Ontwerpt en valideert een afgebakende verbetering van bestaande code, en documenteert de actie en het bewijsmateriaal dat eraan ten grondslag ligt. |
| Redenering | Het document legt de beperkingen, alternatieven en onzekerheden uit en controleert de risico's en het bewijs dat het gedrag behouden is gebleven. |
| Grenzen | Volgt goedgekeurde procedures en vraagt om hulp wanneer informatie of bevoegdheid ontoereikend is. |
Ankers: 0 is afwezig of niet onderbouwd, 1 is gedeeltelijk met relevante weglatingen en 2 is volledig en gerechtvaardigd op basis van overeengekomen criteria. Definieer kritieke fouten apart, zoals gedragsveranderingen zonder dat een test dit had opgemerkt, zodat een algemene score deze niet kan verbergen. Deze rubric is een voorstel, geen gevalideerde gereedheidsnorm: pas deze aan in overleg met een engineeringmanager en test deze in een pilotproject. Onze handleiding voor het ontwerpen van interactieve oefeningen met nuttige feedback laat zien hoe je feedback kunt schrijven die aansluit op beslissingen.
Plan de overdracht zorgvuldig. Geef na de oefening elke engineer een kleine, concrete taak om met een reviewer te bespreken, of voer een korte terugblik uit op een recente wijziging die problemen heeft veroorzaakt. Controleer de overdracht pas nadat de engineer voldoende ervaring heeft opgedaan in de praktijk, niet direct na de workshop.
Waar interactieve levering helpt
Interactieve formats zijn handig wanneer iedereen zich moet vastleggen voordat ze de groep zien. In een live sessie kan een facilitator een kort codefragment laten zien, elke engineer vragen om de eerste wijziging die ze zouden doorvoeren en hoe ze de veiligheid ervan zouden aantonen, in te dienen, en vervolgens de spread onthullen vóór de discussie. Dezelfde prompt kan in een zelfstudieomgeving worden gebruikt ter voorbereiding. AhaSlides ondersteunt interactief leren en de overgang tussen live en zelfstudie. Het is een presentatie- en leertool, geen plek om code uit te voeren of te analyseren, dus voer de refactoring zelf uit in je eigen omgeving. Controleer of de specifieke auteurs-, feedback- of rapportagefuncties die je wilt gebruiken, passen bij je eigen workflow. Voor meer informatie over het kiezen van formats, zie ons artikel over wanneer je adaptief, interactief en live leren moet gebruiken.
Meet wat er veranderd is
Bepaal van tevoren wat zou aantonen dat ingenieurs de taak aankunnen. Vergelijk de kwaliteit van de risicoanalyse en het bewijs van behouden gedrag in een onbekende casus met een basislijn. Definieer wie erbij betrokken is, de noemer en de timing. Als de resultaten verbeteren, controleer dan wat er in dezelfde periode nog meer is veranderd, zoals nieuwe testapparatuur, een snellere productie of een verandering van eigenaar, voordat de verbetering aan de training wordt toegeschreven.
Mogelijke beperkingen die kunnen blijven bestaan
- Tijd voor onderhoudswerkzaamheden. Als er nooit werk aan de schuldenlast wordt ingepland, hebben opgeleide ingenieurs nog steeds geen plek om hun vaardigheden toe te passen.
- Testtools. Zonder een bruikbaar testplatform of een snelle bouwmethode zijn kleine stappen en frequente controles moeilijk vol te houden.
- Dekking van de zaak. Een voorbeeld uit het verleden illustreert een aantal risico's. Een score geeft geen algemene beschrijving van het oordeel van een ingenieur.
- Bepalen wanneer je juist géén refactoring nodig hebt. Sommige code kan beter ongemoeid gelaten worden, vervangen of buiten gebruik gesteld, en die beslissing vereist meer dan alleen vaardigheid.
- Transfer. Prestaties in een kata zijn niet hetzelfde als prestaties in een productiemodule onder leveringsdruk.
Benoem deze problemen vroegtijdig aan de sponsors en plan afzonderlijke oplossingen. Training verbetert wat een engineer kan plannen en aantonen. Het creëert niet de tijd of de benodigde gereedschappen.
Veelgestelde vragen
Wat is een refactoring-trainingsproject?
Het is een gestructureerde werkwijze voor bestaande code, waarbij engineers een kleine wijziging plannen, het bestaande gedrag beschermen met tests, het ontwerp stapsgewijs aanpassen en aantonen dat er niets kapot is gegaan.
Is een volledige herschrijving een goede manier om meer te leren over technische schuld?
Meestal niet. Een volledige herziening is omvangrijk, lastig te valideren en verbergt de vaardigheid die je wilt ontwikkelen. Een afgebakende wijziging met tests die het huidige gedrag vastleggen, maakt de onderliggende redenering zichtbaar.
Hoe beoordeel je of engineers veilig kunnen refactoren?
Geef een nieuwe casus met legacy-code en beoordeel de risicoanalyse en het bewijs dat het gedrag behouden is gebleven aan de hand van overeengekomen criteria. Een quiz over refactoringpatronen bevestigt alleen de vereisten.
Heeft u een voorbeeldcode nodig voor de training?
Je hebt een veilige plek nodig om te oefenen. Veel teams beginnen met een openbare kata en gaan vervolgens over op een afgebakend deel van hun eigen code. Je engineeringmanager moet bevestigen dat de code geschikt is.
Waar te beginnen
Kies één kleine, terugkerende, verouderde wijziging in je codebase. Schrijf een prestatieverklaring, laat een engineeringmanager de situatie en de tests die het behoud van het gedrag aantonen valideren, en stel een beoordelingsschema op met drie criteria op een schaal van 0 tot 2 en een lijst met kritieke fouten. Test het eerst met een kleine groep voordat je het uitrolt.
Om te zien hoe een oefening voor het nemen van refactoringbeslissingen live met je eigen team kan worden uitgevoerd en daarna in eigen tempo kan worden hergebruikt, kun je AhaSlides bekijken.
