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 refaktoravimą kaip kontroliuojama technika esamos kodo bazės dizainui tobulinti, sudarytas iš mažų, elgseną išsaugančių transformacijų. Frazė „elgseną išsaugantis“ skiria refaktoravimą nuo perrašymo, ir tai yra tai, ką mokymas turi padaryti matomą. Pati techninė skolos metafora sugalvojo Wardas Cunninghamas, o Fowlerio diskusija yra naudingas priminimas, kad skolas 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 pozicijos dėl praktikos. Leidėjo aprašyme teigiama, kad ji moko kūrėjus rašyti testus, kurie užtikrina jie netyčia nekeičia programosir kontroliuoti esamą programinę įrangą be visiško perrašymo.
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į.
Paruoš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 atspirties taškas pirmajam žingsniui. Tai README, kurį prižiūri Emily Bache. rekomenduoja prieš keičiant kodą parašyti testus ir šį pratimą apibrėžia kaip praktiką, žengiant mažus žingsnelius, dažnai atliekant testus ir po truputį tobulinant dizainą. Protinga kiekvieno projekto seka yra tokia: apibrėžkite tikslą ir ribas, paraš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 instruktoriaus indėlis ar asinchroninė peržiūra? Tiesioginė analizė suteikia daugiausiai vertės, 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 moderuotą sesiją sudėtingiems atvejams.
4. Pateikite realų pavyzdį
Iliustracinis pavyzdys. Prieš naudodamas atvejį ir atsakymo kriterijus, inžinerijos vadovas turėtų juos patvirtinti.
Byla. 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ų, cituoja 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 bandymas dar kartą. Vertintojas klausia, ką funkcija šiandien atlieka, 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 paličiau 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 sustabdyč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, tačiau kaip planas yra nepilnas, 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 – dalinis su atitinkamais praleidimais, o 2 – išsamus ir pagrįstas pagal sutartus kriterijus. Kritines klaidas apibrėžkite atskirai, 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ų vadovas, skirtas... interaktyvios praktikos kūrimas su naudingu grįžtamuoju ryšiu rodoma, 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šku tempu pasiruošimui. „AhaSlides“ palaiko interaktyvų mokymąsi ir perėjimą tarp tiesioginio ir savarankiško pristatymo. Tai pristatymo ir mokymosi priemonė, o ne vieta, kur galima paleisti ar analizuoti kodą, 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... 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“.
