Komanda manto norēķinu moduli, ko neviens pilnībā nesaprot. Tai nav testu, kas aizsargātu esošo darbību. Tiek piedāvāts sprints, lai to “satīrītu”, un plāns ir pārrakstīt kodolu jaunā struktūrā. Neviens nevar pateikt, kā viņi varētu zināt, ka jaunā versija joprojām pareizi iekasē maksu no klientiem.
Šis ir ilustratīvs scenārijs, nevis dokumentēts incidents. Tas apraksta plaisu, kas jāaizpilda refaktoringa apmācības projektam: inženieri, kuri redz, ka kods ir nekārtīgs, bet vēl nevar plānot ierobežotu uzlabojumu un pierādīt, ka uzvedība ir saglabāta.
Šī rokasgrāmata ir paredzēta inženiertehnisko iespēju vadītājiem un inženiertehniskajiem vadītājiem. Tajā ir aprakstīts, kā aprakstīt veiktspējas problēmu, diagnosticēt nepilnības, sagatavot dizainu un praktizēt to, kā strādāt ar gadījumu un novērtēt, vai prasmes ir piemērojamas reālajam darbam. Tā ir par dizaina apmācību. Jūsu programmas kods, testi un noteikumi ir jāapstiprina vecākajiem inženieriem jūsu pašu stekā.
Kas ir refaktoringa apmācības projekts?
Refaktoringa apmācības projekts ir strukturēts darbs ar mantotu kodu, kura mērķis ir gan spēju veidošana, gan koda uzlabošana. Studenti plāno nelielas, ierobežotas izmaiņas, aizsargā esošo uzvedību ar testiem, uzlabo dizainu nelielos soļos un pierāda, ka nekas nav salūzis. Kods kļūst labāks, un, vēl svarīgāk, inženieri praktizē spriestspēju, kas viņiem būs nepieciešama, strādājot ar reālu tehnisko parādu.
Īsi fakti
| jautājums | Īsā atbilde |
|---|---|
| Kāds ir uzdevums? | Plānojiet un validējiet ierobežota mantojuma koda uzlabojumu. |
| Kādu rezultātu tu iegūsti? | Riska analīze un pierādījumi, ka esošā uzvedība ir saglabāta. |
| Vai plaša pārrakstīšana ir labs apmācību projekts? | Parasti nē. Tas slēpj praktizēto prasmi un apgrūtina saglabātas uzvedības demonstrēšanu. |
| Vai pietiek ar testu par refaktorēšanas modeļiem? | Nē. Tas apstiprina priekšnosacījumus, bet ne to, vai inženieris var plānot un apstiprināt izmaiņas. |
| Kas apstiprina saturu? | Inženierzinātņu vadītājs un vecākais inženieris, kurš pārzina koda bāzi. |
| Ko nevar labot ar treniņiem? | Trūkst testa instrumentu, atbrīvošanas spiediens, neskaidra īpašumtiesības un nav laika apkopes darbiem. |
| Kā tu zini, ka tas nostrādāja? | Jauns, neredzēts mantojuma koda gadījums, kas novērtēts atbilstoši saskaņotiem kritērijiem, ar reāla darba turpmāku izpēti. |
1. Aprakstiet veiktspējas problēmu
Sāciet ar uzdevumu: plānojiet un validējiet ierobežota mantojuma koda uzlabojumu. Svarīgākais vārds ir “ierobežots”. Mācību dalībnieks izvēlas pietiekami mazu izmaiņu, lai to pabeigtu, un var pateikt, kas ietilpst un kas neietilpst darbības jomā.
Ir svarīgi precīzi lietot terminus. Martins Faulers apraksta refaktoringu kā kontrolēta metode esošas koda bāzes dizaina uzlabošanai, kas sastāv no mazām, uzvedību saglabājošām transformācijām. Frāze “uzvedību saglabājoša” ir tas, kas atšķir refaktoringu no pārrakstīšanas, un tieši tas apmācībai ir jāpadara redzams. Pati tehniskā parāda metafora izgudroja Vords Kaningems, un Faulera diskusija ir noderīgs atgādinājums, ka parādu var uzņemties apzināti un apdomīgi, tāpēc ne katrs nekārtīgs modulis ir kļūda, kas jālabo.
Maikla Fetersa grāmata par mantoto kodu ietur tādu pašu nostāju attiecībā uz praksi. Tās izdevēja aprakstā teikts, ka tā māca izstrādātājiem rakstīt testus, kas nodrošina viņi netīšām nemaina lietojumprogrammuun kontrolēt esošo programmatūru bez pilnīgas pārrakstīšanas.
Uzrakstiet veiktspējas aprakstu vienā teikumā un palūdziet inženiertehniskajam vadītājam to pārbaudīt: “Ņemot vērā mantotu moduli un definētu mērķi, inženieris ierosina ierobežotas izmaiņas, pievieno testus, kas nosaka pašreizējo uzvedību, veic izmaiņas nelielos soļos un parāda, ka šī uzvedība ir saglabāta.”
2. Diagnosticējiet mācīšanās un konteksta nepilnības
Pirms jebkādu uzdevumu veidojat, salīdziniet nepieciešamo uzdevumu ar to, ko pašlaik praktizējat, un novērtējiet to. Trīs jautājumi parasti atšķir apmācības plaisu no kaut kā cita:
- Vai pašreizējā praksē tiek izmantots reālais uzdevums? Ja apmācība aptver slaidu refaktorēšanas modeļus, bet neviens nekad nemaina nepārbaudītu kodu, neviens nav praktizējis aizsardzības uzvedību. Ja novērtējums ir tests ar atbilžu variantiem par koda smaržām, tas mēra atcerēšanos.
- Kāda ir kognitīvā prasība? Blūma pārskatītajā taksonomijā izmaiņu drošības novērtēšana notiek analīzes un novērtēšanas līmeņos, savukārt plāna un testu izstrāde sasniedz izveides līmeni. Aktivitāšu saskaņošana ar šiem līmeņiem ir aplūkota mūsu ceļvedī par mācību aktivitāšu saskaņošana ar Blūma taksonomiju.
- Vai kaut kas cits, nevis prasmes, traucē? Pārbaudiet personāla nodrošinājumu, rīkus un procedūras. Ja izveide aizņems stundu, neviens bieži neveiks testus. Ja apkopes darbi nekad netiks ieplānoti, inženieri veiks pārprojektēšanu tikai slepeni. Ziņojiet par iemesliem, kas nav saistīti ar apmācību, cilvēkiem, kuri tos var novērst.
3. Izstrādājiet mērķtiecīgu sagatavošanos un praksi
Kad esat noskaidrojis, kuras nepilnības apmācība var novērst, piešķiriet katram posmam atšķirīgu uzdevumu.
Sagatavošana. Pārbaudiet priekšnosacījumus, veicot īsu diagnostiku: kā darbojas jūsu testa ietvars, kas ir raksturošanas tests un kā jūsu komanda pārskata un apvieno. Šim posmam ir piemērota pašmācība. Atgādināšanas pārbaude apstiprina tikai priekšnosacījumus.
Prakse. Izmantojiet sistemātiskus refaktorēšanas projektus ar skaidru formu. Sāciet ar nelielu, drošu paraugu un pēc tam pārejiet uz reālu, bet ierobežotu savas koda bāzes daļu. Gilded Rose kata ir labi zināms sākumpunkts pirmajam solim. Tās README failu uztur Emīlija Beiča. iesaka rakstīt testus pirms koda maiņas un definē vingrinājumu kā nelielu soļu veikšanu, biežu testu veikšanu un pakāpenisku dizaina uzlabošanu. Saprātīga secība katram projektam ir šāda: definējiet mērķi un robežu, rakstiet testus, kas atspoguļo koda darbību šodien, mainiet vienu lietu vienlaikus, veiciet testus pēc katra soļa un pierakstiet apgūto.
Atsauksmes. Saistiet atsauksmes ar lēmumiem, nevis ar kopējo punktu skaitu. “Jūs ieguvāt atlaides loģiku, bet jūsu testi aptvēra tikai veiksmīgo ceļu, tāpēc jūs, iespējams, nepamanījāt noapaļošanas izmaiņas” ir noderīgāk nekā “3 no 5”.
Tiešraides instruktora ievade vai asinhrona pārskatīšana? Tiešraides ievade sniedz vislielāko vērtību, ja izvēle ir neskaidra, piemēram, vai pārtraukt un pievienot trūkstošu testu vai turpināt. Asinhrona pārskatīšana ir pietiekama, ja studenti salīdzina savu plānu un testus ar anotētu eksperta versiju. Daudzas komandas izmanto abus: vispirms sagatavošanos patstāvīgi, pēc tam vadītu sesiju sarežģītos gadījumos.
4. Izstrādājiet reālistisku piemēru
Ilustratīvi. Inženiertehniskajam vadītājam pirms lietošanas ir jāapstiprina gadījums un atbildes kritēriji.
Lieta. Mantota funkcija aprēķina pasūtījuma kopsummu, ieskaitot atlaidi, nodokli un piegādes noteikumu. Tai nav testu. Komanda ierosina pārstrukturēt visu norēķinu moduli, lai padarītu to “tīrāku”.
Uzdevums. Mācību dalībnieks paskaidro, ko viņš darītu, min pierādījumus, ko viņš apkopotu, un norāda, kāda papildu informācija vai atbalsts viņam ir nepieciešams.
Pirmais mēģinājums. “Es sadalītu moduli trīs pakalpojumos un pārvietotu loģiku, pēc tam pārbaudītu skaitļus izstrādes procesā.” Mācību dalībnieks ir izvēlējies lielas izmaiņas un novēlotu, manuālu pārbaudi. Nav iespējams noteikt, vai vecā un jaunā versija saskan robežgadījumos.
Atsauksmes un mēģinājums vēlreiz. Recenzents jautā, ko funkcija šodien dara tukša groza gadījumā, atlaides gadījumā, kas padara kopsummu negatīvu, un noapaļošanas gadījumā. Atkārtotajā mēģinājumā apmācāmajam tiek lūgts sašaurināt darbības jomu līdz vienai uzvedībai un pateikt, kā viņš pierādītu, ka tā nav mainījusies.
Spēcīgāks mēģinājums. “Es pagaidām atstātu moduļa struktūru mierā. Es testu veidā fiksētu to, ko pasūtījuma kopsummas funkcija atgriež šodien ievades kopai, ieskaitot robežgadījumus. Pēc tam es izvilktu atlaides aprēķinu savā funkcijā, pēc šī viena soļa palaistu testus un apturētu. Es atzīmētu, ka piegādes noteikumam ir uzvedība, ko es nesaprotu, un pirms tam pieskarties, pajautātu kolēģim.” Ievērojiet, ka šī atbilde ierobežo izmaiņas, vispirms aizsargā uzvedību un nosauc to, kas nav zināms.
Kāpēc katra atbilde ir aizstāvama vai nepilnīga. Vērtējiet katru pēc apstiprinātiem kritērijiem, nevis pēc recenzenta vēlmēm. Pirmais mēģinājums var būt saprātīgs ilgtermiņa virziens, taču tas ir nepilnīgs kā plāns, jo tajā nav pierādījumu par saglabātu uzvedību. Spēcīgākais mēģinājums ir neliels, pārbaudāms un godīgs attiecībā uz nenoteiktību.
5. Novērtējiet spējas un plānojiet nodošanu
Spēju pierādījums ir sniegums jaunā mantojuma koda gadījumā, ko students vēl nav redzējis. Novērtējiet riska analīzi un pierādījumus, ka uzvedība ir saglabāta. Vienkāršā rubrikā katram kritērijam tiek izmantota skala no 0 līdz 2:
| Kritērijs | Novērojami pierādījumi |
|---|---|
| Uzdevuma izpilde | Plāno un validē ierobežota mantojuma koda uzlabojumu un reģistrē darbību un tās pamatojumu. |
| Pamatojums | Izskaidro ierobežojumus, alternatīvas un nenoteiktību, kā arī pārbauda riskus un pierādījumus tam, ka uzvedība tika saglabāta. |
| Robežas | Izmanto apstiprinātas procedūras un lūdz palīdzību, ja informācija vai pilnvaras nav pietiekamas. |
Enkuri: 0 nav vai nav pamatoti, 1 ir daļēji ar būtiskiem izlaidumiem un 2 ir pilnīgi un pamatoti ar saskaņotajiem kritērijiem. Atsevišķi definējiet kritiskās kļūdas, piemēram, mainīgu uzvedību bez testa, kas to varētu pamanīt, lai kopējais vērtējums to nevarētu noslēpt. Šī rubrika ir priekšlikums, nevis apstiprināts gatavības standarts: pielāgojiet to kopā ar inženiertehnisko vadītāju un izmēģiniet to. Mūsu ceļvedis interaktīvas prakses izstrāde ar noderīgu atgriezenisko saiti parāda, kā rakstīt atsauksmes, kas saistītas ar lēmumiem.
Apzināti plānojiet pārnesi. Pēc vingrinājuma katram inženierim iedodiet nelielu, reālu parādu, ko risināt ar recenzentu, vai arī veiciet īsu retrospektīvu par nesenām izmaiņām, kas kaut ko sabojāja. Pārbaudiet pārnesi pēc atbilstošas iepazīšanās ar reālu darbu, nevis uzreiz pēc semināra.
Kur palīdz interaktīva piegāde
Interaktīvie formāti palīdz, ja ikvienam ir jāapņemas, pirms viņš redz grupu. Tiešraides sesijā vadītājs var parādīt īsu mantojuma fragmentu, lūgt katram inženierim iesniegt pirmo izmaiņu, ko viņš veiktu, un to, kā viņš pierādītu tās drošību, un pēc tam atklāt izplatību pirms diskusijas. To pašu uzdevumu var izpildīt patstāvīgi sagatavošanās nolūkos. AhaSlides atbalsta interaktīvu mācīšanos un pāreju starp tiešraides un patstāvīgu apmācību. Tas ir prezentāciju un mācību rīks, nevis vieta, kur palaist vai analizēt kodu, tāpēc palaidiet pašu refaktoringu savā vidē. Pārbaudiet jebkuru konkrētu autorēšanas, atsauksmju vai ziņošanas funkciju, uz kuru plānojat paļauties savā darbplūsmā. Lai saņemtu norādījumus par formātu izvēli, skatiet mūsu rakstu par Kad izmantot adaptīvo, interaktīvo un tiešo mācīšanos.
Izmēriet izmaiņas
Iepriekš izlemiet, kas parādītu, ka inženieri spēj veikt uzdevumu. Salīdziniet riska analīzes kvalitāti un saglabātās uzvedības pierādījumus neredzētā gadījumā ar sākotnējo līmeni. Definējiet, kas ir iekļauts, saucēju un laiku. Ja rezultāti uzlabojas, pirms apmācības ieskaitīšanas pārbaudiet, kas vēl ir mainījies tajā pašā laika posmā, piemēram, jauni testēšanas rīki, ātrāka izstrāde vai īpašnieka maiņa.
Ierobežojumi, kas var palikt
- Laiks apkopes darbiem. Ja darbs ar parādiem nekad netiek plānots, apmācītiem inženieriem joprojām nav, kur izmantot šīs prasmes.
- Testēšanas rīki. Bez izmantojamas testa instalācijas vai ātras uzbūves ir grūti veikt nelielus soļus un biežas pārbaudes.
- Lietas pārklājums. Viens mantojuma gadījums parāda dažus riska veidus. Punktu skaits neraksturo inženiera spriedumu kopumā.
- Spriežot pēc brīža, kad nevajadzētu refaktorēt. Dažus kodus labāk atstāt mierā, aizstāt vai noņemt no aprites, un šis lēmums prasa vairāk nekā tikai prasmes.
- Pārskaitījums. Izpildījums kata nav tas pats, kas sniegums ražošanas modulī zem izpildījuma spiediena.
Nosauciet tos sponsoriem jau laikus un plānojiet atsevišķus labojumus. Apmācība uzlabo inženiera iespējas plānot un pierādīt. Tā nerada laiku vai instrumentus.
Biežāk uzdotie jautājumi
Kas ir refaktoringa apmācības projekts?
Tā ir strukturēta prakse ar mantotu kodu, kur inženieri plāno nelielas izmaiņas, aizsargā esošo darbību ar testiem, maina dizainu nelielos soļos un pierāda, ka nekas nav salūzis.
Vai pilnīga pārrakstīšana ir labs veids, kā uzzināt par tehnisko parādu?
Parasti nē. Pārrakstīšana ir liela, grūti validējama un slēpj prasmi, kuru vēlaties attīstīt. Ierobežotas izmaiņas ar testiem, kas fiksē pašreizējo uzvedību, padara spriešanu redzamu.
Kā jūs novērtējat, vai inženieri var droši refaktorēt?
Sniedziet jaunu mantojuma koda gadījumu un novērtējiet riska analīzi un pierādījumus, ka uzvedība tika saglabāta atbilstoši saskaņotajiem kritērijiem. Viktorīna par refaktorēšanas modeļiem apstiprina tikai priekšnosacījumus.
Vai apmācībai ir nepieciešama parauga koda bāze?
Tev ir nepieciešama vieta, kur droši praktizēties. Daudzas komandas sāk ar publisku kata un pēc tam pāriet uz ierobežotu sava koda daļu. Tavam inženiertehniskajam vadītājam ir jāapstiprina, ka kods ir piemērots.
Kur sākt
Izvēlieties vienu nelielu, atkārtotu mantotu izmaiņu veidu savā koda bāzē. Uzrakstiet veiktspējas pārskatu, palūdziet inženierijas vadītājam apstiprināt gadījumu un testus, kas parādītu saglabātu darbību, un izstrādājiet trīs kritēriju rubriku ar skalu no 0 līdz 2 un kritisko kļūdu sarakstu. Pirms ieviešanas izmēģiniet to nelielā grupā.
Lai redzētu, kā refaktoringa lēmumu pieņemšanas vingrinājums varētu noritēt tiešraidē ar jūsu komandu un pēc tam tikt atkārtoti izmantots patstāvīgi, izpētiet AhaSlides.
