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 helpt om precieze termen te gebruiken. Martin Fowler beschrijft refactoring als volgt: een gecontroleerde techniek voor het verbeteren van het ontwerp van een bestaande codebasis, opgebouwd uit kleine, gedragsbehoudende transformaties. De term "gedragsbehoudend" onderscheidt refactoring van een herschrijving en is wat de training duidelijk moet maken. De metafoor van technische schuld zelf. De term werd bedacht door Ward Cunningham.En Fowlers betoog is een nuttige herinnering dat schulden bewust en verstandig kunnen worden aangegaan, dus niet elke rommelige module is een fout die moet worden rechtgezet.
Het boek van Michael Feathers over legacy-code volgt dezelfde praktische benadering. Volgens de beschrijving van de uitgever leert het ontwikkelaars hoe ze tests moeten schrijven die ervoor zorgen dat... Ze veranderen de applicatie niet onbedoeld.en om bestaande software onder controle te krijgen 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.
Praktijk. 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 ervan, onderhouden door Emily Bache, Het wordt aanbevolen om tests te schrijven voordat de code wordt gewijzigd. Het kader voor de oefening wordt gepresenteerd als een training in het nemen van kleine stappen, het regelmatig uitvoeren van 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, verander één ding tegelijk, voer de tests na elke stap uit en noteer 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 de docent of asynchroon nakijken? Live feedback is vooral waardevol wanneer er sprake is van onduidelijkheid, bijvoorbeeld of je moet stoppen en een ontbrekende toets moet toevoegen of door moet gaan. Asynchrone feedback is voldoende wanneer leerlingen hun plan en toetsen vergelijken met een geannoteerde versie van een expert. Veel teams gebruiken beide methoden: 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 zaak. 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 taak. De leerling legt uit wat hij of zij zou doen, noemt het bewijsmateriaal dat hij of zij zou verzamelen en geeft aan welke aanvullende informatie of ondersteuning nodig is.
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 opnieuw proberen. 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 gedragspatroon en uit te leggen hoe hij of zij zou bewijzen dat dit niet is veranderd.
Een serieuzere 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 plan 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 kleinschalig, 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 afzonderlijk, zoals veranderend gedrag zonder dat een test dit had opgemerkt, zodat een algemene score een dergelijke fout niet kan verbergen. Deze rubric is een voorstel, geen gevalideerde gereedheidsnorm: pas deze aan met een engineeringmanager en test deze in een pilotproject. Onze handleiding voor Interactieve oefeningen ontwerpen met nuttige feedback Dit laat zien hoe je feedback schrijft 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 helpen om ervoor te zorgen dat iedereen zich vastlegt voordat ze de groep zien. Tijdens een live sessie kan een facilitator een kort stukje bestaande code 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, aansluiten bij je eigen workflow. Zie ons artikel over het kiezen van formats voor meer informatie. Wanneer moet je adaptief, interactief en live leren inzetten?.
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.
