Komanda paveldi atsiskaitymo modulį, kurio niekas iki galo nesupranta. Joje nėra testų, kurie apsaugotų esamą elgseną. Pasiūlomas sprintas, kad jį „sutvarkytų“, ir planuojama perrašyti branduolį į naują struktūrą. Niekas negali pasakyti, kaip jie žinos, kad naujoji versija vis dar teisingai apmokestina klientus.
Tai iliustracinis scenarijus, o ne dokumentuotas incidentas. Jis apibūdina spragą, kurią turi užpildyti refaktoringo mokymo projektas: inžinieriai, kurie mato, kad kodas yra netvarkingas, bet dar negali suplanuoti riboto patobulinimo ir parodyti, kad elgsena buvo išsaugota.
Šis vadovas skirtas inžinerijos įgūdžių lavinimo vadovams ir inžinerijos vadybininkams. Jame aprašoma, kaip aprašyti našumo problemą, nustatyti spragas, parengti projektą ir jį praktikuoti, išnagrinėti atvejį ir įvertinti, ar įgūdžiai pritaikomi realiame darbe. Jame kalbama apie projektavimo mokymą. Jūsų programos kodą, testus ir taisykles turėtų patvirtinti vyresnieji inžinieriai jūsų pačių serveryje.
Kas yra refaktoringo mokymo projektas?
Refaktoringo mokymo projektas yra struktūrizuotas darbas su senuoju kodu, kurio tikslas – ne tik patobulinti kodą, bet ir ugdyti gebėjimus. Besimokantieji planuoja nedidelį, ribotą pakeitimą, apsaugo esamą elgseną testais, mažais žingsneliais tobulina projektą ir pateikia įrodymų, kad niekas nesugedo. Kodas gerėja ir, dar svarbiau, inžinieriai praktikuojasi priimti sprendimus, kurių jiems reikės dirbant su realiomis techninėmis problemomis.
Greiti faktai
| klausimas | Trumpas atsakymas |
|---|---|
| Kokia užduotis? | Suplanuoti ir patvirtinti riboto senojo kodo patobulinimą. |
| Ką skaičiuoji? | Rizikos analizė ir įrodymai, kad esamas elgesys buvo išsaugotas. |
| Ar platus perrašymas yra geras mokymo projektas? | Paprastai ne. Tai paslepia lavinamą įgūdį ir apsunkina išsaugoto elgesio demonstravimą. |
| Ar pakanka testo apie refaktoringo šablonų kūrimą? | Ne. Tai patvirtina prielaidas, bet ne tai, ar inžinierius gali suplanuoti ir patvirtinti pakeitimą. |
| Kas patvirtina turinį? | Inžinerijos vadovas ir vyresnysis inžinierius, išmanantis kodų bazę. |
| Ko negali išspręsti treniruotės? | Trūksta bandymo įrankių, išleidimo slėgis, neaiškus savininkas ir laiko stoka techninės priežiūros darbams. |
| Iš kur žinai, kad suveikė? | Naujas, dar nematytas senojo kodo atvejis, įvertintas pagal sutartus kriterijus, su tolesniais realaus darbo rezultatais. |
1. Aprašykite našumo problemą
Pradėkite nuo užduoties: suplanuokite ir patvirtinkite apriboto senojo kodo patobulinimą. Svarbiausias žodis yra „apribotas“. Besimokantysis pasirenka pakankamai mažą pakeitimą, kad jį užbaigtų, ir gali pasakyti, kas patenka į taikymo sritį, o kas ne.
Naudinga tiksliai vartoti terminus. Martinas Fowleris apibūdina refaktoringą kaip kontroliuojamą techniką, skirtą esamos kodo bazės , sudarytos iš mažų, elgseną išsaugančių transformacijų, dizainui tobulinti. Frazė „elgseną išsaugantis“ skiria refaktoringą nuo perrašymo, ir tai turi būti matoma mokymo metu. Pačią techninės skolos metaforą sugalvojo Wardas Cunninghamas , o Fowlerio diskusija yra naudingas priminimas, kad skolą galima prisiimti sąmoningai ir apdairiai, todėl ne kiekvienas netvarkingas modulis yra klaida, kurią reikia taisyti.
Michaelo Featherso knyga apie senąjį kodą laikosi tos pačios praktikos. Leidėjo aprašyme teigiama, kad ji moko kūrėjus rašyti testus, užtikrinančius, kad jie netyčia nekeistų programos , ir valdyti esamą programinę įrangą jos visiškai neperrašant.
Vienu sakiniu parašykite našumo teiginį ir paprašykite inžinerijos vadovo jį patikrinti: „Atsižvelgiant į esamą modulį ir apibrėžtą tikslą, inžinierius pasiūlo ribotą pakeitimą, prideda testus, kurie nustato dabartinį elgesį, atlieka pakeitimą mažais žingsneliais ir parodo, kad elgesys išsaugomas.“
2. Nustatykite mokymosi ir konteksto spragas
Prieš ką nors kurdami, palyginkite reikiamą užduotį su tuo, ką praktikuojate savo dabartinėje veikloje, ir įvertinkite ją. Trys klausimai paprastai skiria mokymo spragą nuo kažko kito:
- Ar dabartinė praktika naudoja tikrąją užduotį? Jei mokymai apima skaidrėse esančių pertvarkymo šablonų taikymą, bet niekas niekada nekeičia nepatikrinto kodo, niekas nėra praktikavęs apsaugos elgesio. Jei vertinimas yra testas su keliais atsakymų variantais, skirtas kodo kvapams analizuoti, jis matuoja įsiminimą.
- Koks yra kognityvinis poreikis? Pagal atnaujintą Bloomo taksonomiją, vertinimas, ar pakeitimas yra saugus, atliekamas analizės ir vertinimo lygmenyse, o plano ir testų kūrimas – kūrimo lygmenyje. Veiklų priskyrimas šiems lygmenims aprašytas mūsų vadove. mokymosi veiklų derinimas su Bloomo taksonomija.
- Ar kliūčių kelia kažkas kita, o ne įgūdžiai? Patikrinkite personalą, įrankius ir procedūras. Jei kūrimas užtruks valandą, niekas dažnai neatliks bandymų. Jei priežiūros darbai niekada nebus suplanuoti, inžinieriai taisys klaidas tik slapta. Praneškite apie su mokymais nesusijusias priežastis žmonėms, kurie gali jas išspręsti.
3. Planuokite tikslingą pasiruošimą ir praktiką
Kai žinosite, kurias spragas mokymai gali užpildyti, kiekvienam etapui paskirkite atskirą užduotį.
Pasiruošimas. Patikrinkite privalomus dalykus atlikdami trumpą diagnozę: kaip veikia jūsų testavimo sistema, kas yra apibūdinimo testas ir kaip jūsų komanda peržiūri bei sujungia rezultatus. Šiam etapui tinka savarankiškas mokymasis. Prisiminimo patikrinimas patvirtina tik privalomus dalykus.
Praktika. Naudokite sistemingus pertvarkymo projektus su aiškia forma. Pradėkite nuo mažo, saugaus pavyzdžio, tada pereikite prie realios, bet apribotos savo kodo bazės dalies. „Gilded Rose“ kata yra gerai žinomas pirmojo žingsnio atspirties taškas. Jos README, kurią tvarko Emily Bache, rekomenduoja rašyti testus prieš keičiant kodą ir šį pratimą apibrėžia kaip praktiką žengiant mažus žingsnelius, dažnai atliekant testus ir palaipsniui tobulinant dizainą. Protinga kiekvieno projekto seka yra tokia: apibrėžkite tikslą ir ribas, rašykite testus, kurie užfiksuotų, ką kodas daro šiandien, keiskite po vieną dalyką, atlikite testus po kiekvieno žingsnio ir užsirašykite, ko išmokote.
Atsiliepimai. Susiekite atsiliepimus su sprendimais, o ne su bendru balu. „Jūs išskyrėte nuolaidos logiką, bet jūsų testai apėmė tik laimingą kelią, todėl negalėjote pastebėti apvalinimo pokyčio“ yra naudingiau nei „3 iš 5“.
Tiesioginis dėstytojo indėlis ar asinchroninė peržiūra? Tiesioginis indėlis yra vertingiausias, kai pasirinkimas yra dviprasmiškas, pavyzdžiui, ar sustabdyti ir pridėti trūkstamą testą, ar tęsti. Asinchroninės peržiūros pakanka, kai besimokantieji lygina savo planą ir testus su anotuota eksperto versija. Daugelis komandų naudoja abu metodus: pirmiausia savarankišką pasiruošimą, o vėliau moderuojamą sesiją sudėtingiems atvejams.
4. Pateikite realų pavyzdį
Iliustracinis pavyzdys. Prieš naudodamas atvejį ir atsakymo kriterijus, inžinerijos vadovas turėtų juos patvirtinti.
Atvejis. Senoji funkcija apskaičiuoja bendrą užsakymo sumą, įskaitant nuolaidą, mokestį ir pristatymo taisyklę. Ji neturi testų. Komanda siūlo pertvarkyti visą atsiskaitymo modulį, kad jis būtų „švaresnis“.
Užduotis. Besimokantysis paaiškina, ką darytų, pateikia surinktus įrodymus ir nurodo, kokios papildomos informacijos ar pagalbos jam reikia.
Pirmas bandymas. „Padalyčiau modulį į tris paslaugas ir perkelčiau logiką, tada patikrinčiau skaičius testavimo metu.“ Besimokantysis pasirinko didelį pakeitimą ir vėlyvą, rankinį patikrinimą. Nėra jokio būdo pasakyti, ar senoji ir naujoji versijos sutampa kraštutiniais atvejais.
Atsiliepimas ir pakartotinis bandymas. Vertintojas klausia, ką funkcija šiandien daro, kai krepšelis tuščias, nuolaida, dėl kurios suma yra neigiama, ir apvalinimo atveju. Pakartotinio bandymo metu besimokančiojo prašoma susiaurinti taikymo sritį iki vieno elgesio ir nurodyti, kaip jis įrodytų, kad jis nepasikeitė.
Stipresnis bandymas. „Kol kas palikite modulio struktūrą ramybėje. Užfiksuočiau, ką užsakymo sumos funkcija šiandien grąžina pagal įvesties rinkinį, įskaitant kraštinius atvejus, kaip testus. Tada išskirčiau nuolaidos skaičiavimą į atskirą funkciją, po šio vieno žingsnio paleisčiau testus ir sustočiau. Atkreipčiau dėmesį, kad siuntimo taisyklė turi elgesį, kurio nesuprantu, ir prieš ją liesdamas paklausčiau kolegos.“ Atkreipkite dėmesį, kad šis atsakymas apriboja pakeitimą, pirmiausia apsaugo elgesį ir įvardija tai, kas nežinoma.
Kodėl kiekvienas atsakymas yra pagrįstas arba neišsamus. Įvertinkite kiekvieną pagal patvirtintus kriterijus, o ne recenzento pageidavimus. Pirmasis bandymas gali būti protinga ilgalaikė kryptis, bet kaip planas yra neišsamus, nes jame nėra jokių išsaugoto elgesio įrodymų. Stipresnis bandymas yra nedidelis, patikrinamas ir sąžiningas dėl neapibrėžtumo.
5. Įvertinkite pajėgumus ir planuokite perdavimą
Gebėjimo įrodymas yra naujo, su senuoju kodu susijusio atvejo, kurio besimokantysis nėra matęs, atlikimas. Įvertinkite rizikos analizę ir įrodymus, kad elgesys buvo išsaugotas. Paprastoje vertinimo skalėje kiekvienam kriterijui naudojama 0–2 balų skalė:
| kriterijus | Stebimi įrodymai |
|---|---|
| Užduoties vykdymas | Suplanuoja ir patvirtina riboto senojo kodo patobulinimą, taip pat užfiksuoja veiksmą ir jo įrodymus. |
| Priežastys | Paaiškina apribojimus, alternatyvas ir neapibrėžtumą, patikrina riziką ir įrodymus, kad elgesys buvo išsaugotas. |
| Ribos | Taiko patvirtintas procedūras ir prašo pagalbos, kai informacijos ar įgaliojimų nepakanka. |
Pagrindiniai kriterijai: 0 – nėra arba neparemta, 1 – dalinė su atitinkamais praleidimais, o 2 – išsami ir pagrįsta pagal sutartus kriterijus. Atskirai apibrėžkite kritines klaidas, pvz., besikeičiantį elgesį be jokio testo, kuris būtų pastebėtas, kad bendras balas negalėtų jų paslėpti. Ši vertinimo skalė yra pasiūlymas, o ne patvirtintas pasirengimo standartas: pritaikykite ją kartu su inžinerijos vadovu ir išbandykite. Mūsų interaktyvios praktikos, kurioje pateikiami naudingi atsiliepimai, kūrimo vadovas parodo, kaip rašyti atsiliepimus, susietus su sprendimais.
Sąmoningai planuokite perkėlimą. Po pratimo kiekvienam inžinieriui duokite nedidelę, realią skolą, kurią jis galėtų aptarti su recenzentu, arba trumpai apžvelkite neseniai atliktą pakeitimą, kuris kažką sugadino. Patikrinkite perkėlimą po tinkamos patirties su realiu darbu, o ne iškart po seminaro.
Kur padeda interaktyvus pristatymas
Interaktyvūs formatai padeda, kai visi turi įsipareigoti prieš pamatydami grupę. Tiesioginės sesijos metu moderatorius gali parodyti trumpą ištrauką, paprašyti kiekvieno inžinieriaus pateikti pirmąjį pakeitimą, kurį jie atliktų, ir kaip jie įrodytų jo saugumą, o tada atskleisti išdėstymą prieš diskusiją. Ta pati užduotis gali būti vykdoma savarankiškame tempe pasiruošimui. „AhaSlides“ palaiko interaktyvų mokymąsi ir perėjimą tarp tiesioginio ir savarankiško pristatymo. Tai pristatymo ir mokymosi priemonė, o ne vieta kodui paleisti ar analizuoti, todėl paleiskite patį pertvarkymą savo aplinkoje. Patikrinkite visas konkrečias kūrimo, atsiliepimų ar ataskaitų teikimo funkcijas, kuriomis planuojate remtis savo darbo eigoje. Norėdami gauti informacijos apie formatų pasirinkimą, žr. mūsų straipsnį apie tai, kada naudoti adaptyvų, interaktyvų ir tiesioginį mokymąsi.
Išmatuokite, kas pasikeitė
Iš anksto nuspręskite, kas parodytų, kad inžinieriai gali atlikti užduotį. Palyginkite rizikos analizės kokybę ir išsaugoto elgesio įrodymus nematomu atveju su pradiniais duomenimis. Apibrėžkite, kas įtraukiama, vardiklį ir laiką. Jei rezultatai pagerėja, prieš įskaitydami mokymus, patikrinkite, kas dar pasikeitė per tą patį laikotarpį, pavyzdžiui, nauji testavimo įrankiai, greitesnis kūrimas ar nuosavybės pasikeitimas.
Apribojimai, kurie gali likti
- Laikas techninės priežiūros darbams. Jei darbas su skolomis niekada nesuplanuojamas, apmokyti inžinieriai vis tiek neturi kur panaudoti šio įgūdžio.
- Bandymo įrankiai. Neturint tinkamo naudoti bandymų laido ar greito surinkimo, sunku išlaikyti mažus žingsnelius ir dažnus patikrinimus.
- Bylos aprėptis. Vienas ankstesnis atvejis rodo keletą rizikos rūšių. Įvertinimas neapibūdina inžinieriaus sprendimo apskritai.
- Sprendžiant, kada nereikėtų refaktoruoti. Kai kurį kodą geriau palikti nepakeistą, pakeisti arba pašalinti iš programos, ir tam reikia daugiau nei įgūdžių.
- Perdavimo. Pasirodymas kata metu nėra tas pats, kas pasirodymas produkcijos modulyje esant spaudimui.
Iš anksto įvardinkite šiuos dalykus rėmėjams ir planuokite atskirus taisymus. Mokymai pagerina inžinieriaus galimybes planuoti ir įrodyti. Jie nesukuria laiko ar įrankių.
Dažnai užduodami klausimai
Kas yra refaktoringo mokymo projektas?
Tai struktūrizuota praktika su senuoju kodu, kai inžinieriai planuoja nedidelį pakeitimą, apsaugo esamą elgseną bandymais, keičia projektą mažais žingsneliais ir įrodo, kad niekas nesugedo.
Ar visiškas perrašymas yra geras būdas sužinoti apie techninę skolą?
Paprastai ne. Perrašymas yra didelis, sunkiai patvirtinamas ir paslepia įgūdį, kurį norite lavinti. Ribotas pakeitimas su testais, kurie fiksuoja dabartinį elgesį, leidžia matyti samprotavimus.
Kaip vertinate, ar inžinieriai gali saugiai refaktoruoti?
Pateikite naują senojo kodo atvejį ir įvertinkite rizikos analizę bei įrodymus, kad elgsena buvo išsaugota pagal sutartus kriterijus. Viktorina apie pertvarkymo šablonus patvirtina tik išankstinius reikalavimus.
Ar jums reikia pavyzdinės kodų bazės mokymams?
Jums reikia vietos, kur saugiai praktikuotis. Daugelis komandų pradeda nuo viešos kata, o tada pereina prie ribotos savo kodo dalies. Jūsų inžinerijos vadovas turėtų patvirtinti, kad kodas yra tinkamas.
Kur pradėti
Pasirinkite vieną nedidelį, pasikartojantį pakeitimą savo kodo bazėje. Parašykite našumo ataskaitą, paprašykite inžinerijos vadovo patvirtinti atvejį ir testus, kurie parodytų išsaugotą veikimą, ir sukurkite trijų kriterijų vertinimo skalę nuo 0 iki 2 ir kritinių klaidų sąrašą. Prieš diegdami, išbandykite ją su maža grupe.
Norėdami sužinoti, kaip refaktoringo sprendimų priėmimo pratimas galėtų būti vykdomas tiesiogiai su jūsų komanda ir vėliau pakartotinai panaudotas savarankiškai, peržiūrėkite „AhaSlides“.
