Tím zdedí fakturačný modul, ktorému nikto úplne nerozumie. Nemá žiadne testy, ktoré by chránili existujúce správanie. Navrhne sa sprint na jeho „vyčistenie“ a plán je prepísať jadro do novej štruktúry. Nikto nevie povedať, ako by vedel, že nová verzia stále správne účtuje zákazníkom.
Toto je ilustratívny scenár, nie zdokumentovaný incident. Opisuje medzeru, ktorú musí projekt školenia refaktoringu vyplniť: inžinieri, ktorí vidia, že kód je chaotický, ale zatiaľ nedokážu naplánovať ohraničené zlepšenie a preukázať, že správanie bolo zachované.
Táto príručka je určená pre vedúcich pracovníkov v oblasti inžinierskeho vzdelávania a manažérov inžinierstva. Zaoberá sa tým, ako opísať problém s výkonom, diagnostikovať nedostatky, pripraviť a precvičiť návrh, prepracovať prípad a posúdiť, či sa zručnosť prenesie do skutočnej praxe. Ide o návrh školení. Kód, testy a pravidlá vo vašom programe by mali byť overené vedúcimi inžiniermi na vašom vlastnom stacku.
Čo je to školiaci projekt refaktoringu?
Školiaci projekt refaktoringu je štruktúrovaná práca na staršom kóde, ktorej cieľom je budovať schopnosti, ako aj vylepšovať kód. Študujúci plánujú malé, ohraničené zmeny, chránia existujúce správanie testami, vylepšujú dizajn v malých krokoch a preukazujú, že nič sa nepokazilo. Kód sa zlepšuje a čo je dôležitejšie, inžinieri si precvičujú úsudok, ktorý budú potrebovať na základe skutočného technického dlhu.
Rýchle fakty
| Otázka | Stručná odpoveď |
|---|---|
| Aká je úloha? | Naplánujte a overte vylepšenie ohraničeného staršieho kódu. |
| Aké skóre dosiahnete? | Analýza rizika a dôkazy o zachovaní existujúceho správania. |
| Je rozsiahle prepísanie dobrý tréningový projekt? | Zvyčajne nie. Zakrýva to precvičovanú zručnosť a sťažuje prejavenie zachovaného správania. |
| Stačí kvíz o refaktoringových vzoroch? | Nie. Potvrdzuje predpoklady, ale nie to, či inžinier dokáže naplánovať a overiť zmenu. |
| Kto overuje obsah? | Manažér inžinierstva a vedúci inžinier, ktorý pozná kódovú základňu. |
| Čo tréning nedokáže vyriešiť? | Chýbajúce testovacie nástroje, uvoľňovací tlak, nejasné vlastníctvo a nedostatok času na údržbárske práce. |
| Ako vieš, že to fungovalo? | Nový, doposiaľ nevidený prípad s použitím staršieho kódu, hodnotený podľa dohodnutých kritérií, s následnou analýzou skutočnej práce. |
1. Popíšte problém s výkonom
Začnite s úlohou: naplánujte a overte ohraničené vylepšenie staršieho kódu. Dôležité slovo je „ohraničené“. Študent si vyberie zmenu dostatočne malú na dokončenie a vie povedať, čo je a čo nie je v rozsahu.
Je užitočné byť presný v termínoch. Martin Fowler opisuje refaktoring ako kontrolovaná technika na zlepšenie návrhu existujúcej kódovej základne, pozostávajúce z malých transformácií zachovávajúcich správanie. Slovné spojenie „zachovávajúce správanie“ je to, čo odlišuje refaktoring od prepisovania a je to to, čo musí školenie zviditeľniť. Samotná metafora technického dlhu vymyslel Ward Cunninghama Fowlerova diskusia je užitočnou pripomienkou, že dlh sa dá brať zámerne a obozretne, takže nie každý chaotický modul je chybou, ktorú treba opraviť.
Kniha Michaela Feathersa o legacy kóde sa v praxi vyjadruje rovnako. Vydavateľ v popise uvádza, že učí vývojárov písať testy, ktoré zabezpečia nemenia aplikáciu neúmyselnea dostať existujúci softvér pod kontrolu bez jeho úplného prepísania.
Napíšte vyhlásenie o výkonnosti v jednej vete a nechajte ho skontrolovať technickým manažérom: „Vzhľadom na starší modul a definovaný cieľ, technický inžinier navrhne ohraničenú zmenu, pridá testy, ktoré určia aktuálne správanie, vykoná zmenu v malých krokoch a ukáže, že správanie sa zachovalo.“
2. Diagnostikovať medzery vo vzdelávaní a kontexte
Predtým, ako niečo postavíte, porovnajte požadovanú úlohu s tým, čo v súčasnosti precvičujete a zhodnoťte. Medzeru v tréningu od niečoho iného zvyčajne oddeľujú tri otázky:
- Využíva súčasná prax skutočnú úlohu? Ak školenie zahŕňa vzory refaktoringu v slajdoch, ale nikto nikdy nezmení neotestovaný kód, nikto si neprecvičoval ochranné správanie. Ak je hodnotenie testom s výberom odpovede na pachy kódu, meria zapamätanie si.
- Aký je kognitívny dopyt? V Bloomovej revidovanej taxonómii sa posudzovanie bezpečnosti zmeny vykonáva na úrovni analýzy a hodnotenia a návrh plánu a testov sa dosahuje na úrovni tvorby. Priraďovanie aktivít k týmto úrovniam je popísané v našom sprievodcovi priraďovanie vzdelávacích aktivít k Bloomovej taxonómii.
- Stojí v ceste niečo iné ako zručnosť? Skontrolujte personálne obsadenie, nástroje a postupy. Ak zostavenie trvá hodinu, nikto nebude často vykonávať testy. Ak sa údržbárske práce nikdy nenaplánujú, inžinieri budú refaktorovať iba tajne. Príčiny, ktoré nie sú spojené so školením, nahláste ľuďom, ktorí ich môžu opraviť.
3. Navrhnite zmysluplnú prípravu a prax
Keď zistíte, ktoré medzery dokáže tréning vyplniť, dajte každej fáze špecifickú úlohu.
Príprava. Skontrolujte predpoklady pomocou krátkej diagnostiky: ako funguje váš testovací rámec, čo je charakterizačný test a ako váš tím vykonáva kontroly a zlučovania. Do tejto fázy je vhodné štúdium vlastným tempom. Kontrola opakovania potvrdzuje iba predpoklady.
Praxou. Používajte systematické refaktoringové projekty s jasnou štruktúrou. Začnite na malej, bezpečnej vzorke a potom prejdite na skutočnú, ale ohraničenú časť vlastnej kódovej základne. Kata Gilded Rose je známym východiskovým bodom pre prvý krok. Jeho súbor README, ktorý spravuje Emily Bache, odporúča napísať testy pred zmenou kódu a cvičenie chápe ako precvičovanie malých krokov, častého spúšťania testov a postupného vylepšovania dizajnu. Rozumná postupnosť pre každý projekt je: definovať cieľ a hranice, napísať testy, ktoré zachytávajú, čo kód robí dnes, meniť jednu vec po druhej, spúšťať testy po každom kroku a zapísať si, čo ste sa naučili.
Spätná väzba. Prepojte spätnú väzbu s rozhodnutiami, nie s celkovým skóre. „Vybrali ste logiku zliav, ale vaše testy pokrývali iba šťastnú cestu, takže ste si zmenu zaokrúhľovania nemohli všimnúť“ je užitočnejšie ako „3 z 5“.
Živý vstup inštruktora alebo asynchrónna kontrola? Živý vstup je najhodnotnejší, keď je voľba nejednoznačná, napríklad či prestať a pridať chýbajúci test alebo pokračovať. Asynchrónne opakovanie je postačujúce, keď študenti porovnávajú svoj plán a testy s anotovanou verziou pre odborníkov. Mnohé tímy používajú oboje: najprv prípravu vlastným tempom a potom facilitované stretnutie na zložitých prípadoch.
4. Vypracujte realistický príklad
Ilustrácia. Manažér technických oddelení by mal pred použitím overiť prípad a kritériá odpovede.
Púzdro. Staršia funkcia vypočítava celkovú sumu objednávky vrátane zľavy, dane a pravidla dopravy. Nemá žiadne testy. Tím navrhuje reštrukturalizáciu celého fakturačného modulu, aby bol „prehľadnejší“.
Úloha. Študent vysvetlí, čo by urobil, uvedie dôkazy, ktoré by zhromaždil, a povie, aké ďalšie informácie alebo podporu potrebuje.
Prvý pokus. „Rozdelil by som modul na tri služby a presunul logiku, potom by som skontroloval čísla v štádiu prípravy.“ Študent si zvolil veľkú zmenu a neskorú manuálnu kontrolu. Neexistuje spôsob, ako zistiť, či sa stará a nová verzia zhodujú v okrajových prípadoch.
Spätná väzba a pokus znova. Recenzent sa pýta, čo funkcia robí dnes pre prázdny košík, zľavu, ktorá spôsobí zápornú celkovú sumu, a prípad zaokrúhľovania. Pri opakovanom pokuse sa študent pýta, či má zúžiť rozsah na jedno správanie a ako by dokázal, že sa nezmenilo.
Silnejší pokus. „Štruktúru modulu by som zatiaľ nechal tak. Zachytil by som, čo dnes vráti funkcia Order Total pre množinu vstupov vrátane okrajových prípadov, ako testy. Potom by som extrahoval výpočet zľavy do jej vlastnej funkcie, spustil testy po tomto jedinom kroku a zastavil by som. Všimol by som si, že pravidlo prepravy má správanie, ktorému nerozumiem, a predtým, ako by som sa ho dotkol, by som sa opýtal kolegu.“ Všimnite si, že táto odpoveď obmedzuje zmenu, najprv chráni správanie a pomenúva to, čo je neznáme.
Prečo je každá odpoveď obhájiteľná alebo neúplná. Každý pokus posudzujte podľa schválených kritérií, nie podľa preferencií hodnotiteľa. Prvý pokus môže byť rozumným dlhodobým smerom, ale ako plán je neúplný, pretože neprináša žiadne dôkazy o zachovanom správaní. Silnejší pokus je malý, overiteľný a úprimný, čo sa týka neistoty.
5. Posúdenie spôsobilosti a plánovanie prenosu
Dôkazom schopnosti je výkon na novom prípade so starším kódom, ktorý študent ešte nevidel. Ohodnoťte analýzu rizík a dôkaz, že správanie bolo zachované. Jednoduchá rubrika používa stupnicu od 0 do 2 pre každé kritérium:
| kritérium | Pozorovateľné dôkazy |
|---|---|
| Vykonanie úlohy | Plánuje a overuje vylepšenie ohraničeného staršieho kódu a zaznamenáva akciu a dôkazy, ktoré za ňou stoja. |
| uvažovanie | Vysvetľuje obmedzenia, alternatívy a neistotu a kontroluje riziká a dôkazy o tom, že správanie bolo zachované. |
| Hranice | Používa schválené postupy a žiada o pomoc, keď informácie alebo autorita nie sú dostatočné. |
Kotvy: 0 chýba alebo nie je podložené, 1 je čiastočné s relevantnými opomenutiami a 2 je úplné a zdôvodnené podľa dohodnutých kritérií. Kritické chyby definujte samostatne, napríklad zmenu správania bez testu, ktorý by si ju všimol, takže celkové skóre ich nemôže skryť. Táto rubrika je návrh, nie validovaný štandard pripravenosti: upravte ju s technickým manažérom a pilotne ju overte. Náš sprievodca navrhovanie interaktívnych cvičení s užitočnou spätnou väzbou ukazuje, ako napísať spätnú väzbu, ktorá odkazuje na rozhodnutia.
Prenos plánujte zámerne. Po cvičení dajte každému inžinierovi malý, skutočný dlh, ktorý má prediskutovať s hodnotiteľom, alebo urobte krátku retrospektívu nedávnej zmeny, ktorá niečo pokazila. Prenos skontrolujte po vhodnom vystavení sa skutočnej práci, nie hneď po workshope.
Kde pomáha interaktívne doručovanie
Interaktívne formáty pomáhajú pri zavádzaní všetkých krokov pred stretnutím so skupinou. V živej relácii môže facilitátor ukázať krátky úryvok staršieho kódu, požiadať každého inžiniera, aby predložil prvú zmenu, ktorú by urobil, a ako by dokázal jej bezpečnosť, a potom odhaliť rozloženie pred diskusiou. Rovnaká výzva môže prebiehať vlastným tempom na prípravu. AhaSlides podporuje interaktívne učenie a prechod medzi živou a vlastnou reláciou. Je to nástroj na prezentáciu a vzdelávanie, nie miesto na spúšťanie alebo analýzu kódu, preto spustite samotný refaktoring vo svojom vlastnom prostredí. Skontrolujte všetky konkrétne funkcie tvorby obsahu, spätnej väzby alebo reportovania, na ktoré sa plánujete spoľahnúť, v porovnaní s vaším vlastným pracovným postupom. Pokyny k výberu formátov nájdete v našom článku o kedy použiť adaptívne, interaktívne a živé učenie.
Zmerajte, čo sa zmenilo
Vopred sa rozhodnite, čo by preukázalo, že inžinieri dokážu úlohu zvládnuť. Porovnajte kvalitu analýzy rizík a dôkazy o zachovanom správaní na nevidenom prípade s východiskovým stavom. Definujte, kto je zahrnutý, menovateľa a načasovanie. Ak sa výsledky zlepšia, pred priznaním zápočtu za školenie skontrolujte, čo sa ešte zmenilo v rovnakom období, ako napríklad nové testovacie nástroje, rýchlejšia konštrukcia alebo zmena vlastníctva.
Obmedzenia, ktoré môžu pretrvávať
- Čas na údržbárske práce. Ak sa práca na dlhu nikdy neplánuje, vyškolení inžinieri stále nemajú kde túto zručnosť využiť.
- Testovacie nástroje. Bez použiteľného testovacieho postroja alebo rýchlej montáže je ťažké udržať malé kroky a časté kontroly.
- Krytie prípadu. Jeden starší prípad ukazuje niekoľko druhov rizika. Skóre vo všeobecnosti neopisuje úsudok inžiniera.
- Posúdenie, kedy nerobiť refaktoring. Niektorý kód je lepšie nechať tak, nahradiť ho alebo vyradiť z prevádzky a toto rozhodnutie si vyžaduje viac než len zručnosť.
- Transfer. Výkon v kata nie je to isté ako výkon v produkčnom module pod tlakom.
Včas ich pomenujte sponzorom a naplánujte samostatné opravy. Školenie zlepšuje to, čo dokáže inžinier naplánovať a dokázať. Nevytvára čas ani nástroje.
Často kladené otázky
Čo je to školiaci projekt refaktoringu?
Ide o štruktúrovanú prax na staršom kóde, kde inžinieri plánujú malé zmeny, chránia existujúce správanie testami, menia dizajn v malých krokoch a ukazujú, že sa nič nepokazilo.
Je úplné prepísanie dobrý spôsob, ako sa dozvedieť viac o technickom dlhu?
Zvyčajne nie. Prepísanie je rozsiahle, ťažko sa overuje a skrýva zručnosť, ktorú chcete rozvíjať. Ohraničená zmena s testami, ktoré zachytávajú aktuálne správanie, zviditeľňuje zdôvodnenie.
Ako hodnotíte, či inžinieri dokážu bezpečne refaktorovať?
Uveďte nový prípad s legacy kódom a ohodnoťte analýzu rizík a dôkazy o zachovaní správania podľa dohodnutých kritérií. Kvíz o vzoroch refaktoringu potvrdzuje iba predpoklady.
Potrebujete vzorovú kódovú základňu pre školenie?
Potrebujete miesto na bezpečné precvičovanie. Mnoho tímov začína s verejným kata a potom prechádza na ohraničenú časť vlastného kódu. Váš technický manažér by mal potvrdiť, že kód je vhodný.
Kde začať
Vyberte si jednu malú, opakujúcu sa zmenu vo vašej kódovej základni. Napíšte vyhlásenie o výkonnosti, nechajte manažéra technického oddelenia overiť prípad a testy, ktoré by preukázali zachované správanie, a vypracujte trojkritériovú rubriku so stupnicou od 0 do 2 a zoznamom kritických chýb. Pred spustením ju otestujte v malej skupine.
Ak chcete vidieť, ako by sa rozhodovacie cvičenie o refaktoringu mohlo spustiť naživo s vaším vlastným tímom a následne ho znovu použiť vlastným tempom, preskúmajte AhaSlides.
