Tim nasljeđuje modul za naplatu koji nitko u potpunosti ne razumije. Nema testove koji štite postojeće ponašanje. Predlaže se sprint za njegovo "čišćenje", a plan je prepisati jezgru u novu strukturu. Nitko ne može reći kako bi znao da nova verzija i dalje ispravno naplaćuje kupce.
Ovo je ilustrativni scenarij, a ne dokumentirani incident. Opisuje jaz koji projekt obuke za refaktoriranje mora popuniti: inženjeri koji mogu vidjeti da je kod neuredan, ali još ne mogu planirati ograničeno poboljšanje i pokazati da je ponašanje sačuvano.
Ovaj vodič namijenjen je voditeljima inženjerskog osposobljavanja i inženjerskim menadžerima. Obuhvaća kako opisati problem s performansama, dijagnosticirati nedostatke, pripremiti i provesti praksu dizajna, proći kroz studiju slučaja i procijeniti prenosi li se vještina na stvarni rad. Radi se o dizajnu obuke. Kod, testove i pravila u vašem programu trebaju validirati viši inženjeri na vašem vlastitom programu.
Što je projekt obuke za refaktoriranje?
Projekt obuke za refaktoriranje je strukturirani rad na naslijeđenom kodu, čija je svrha izgradnja sposobnosti, kao i poboljšanje koda. Polaznici planiraju malu, ograničenu promjenu, štite postojeće ponašanje testovima, poboljšavaju dizajn u malim koracima i pokazuju dokaze da ništa nije pokvareno. Kod postaje bolji i, što je još važnije, inženjeri vježbaju prosudbu koja će im biti potrebna o stvarnom tehničkom dugu.
Brze činjenice
| Pitanje | Kratak odgovor |
|---|---|
| Koji je zadatak? | Planirajte i validirajte ograničeno poboljšanje naslijeđenog koda. |
| Koji rezultat postižeš? | Analiza rizika i dokazi da je postojeće ponašanje očuvano. |
| Je li široko prepisivanje dobar projekt obuke? | Obično ne. Skriva vještinu koja se vježba i otežava prikazivanje sačuvanog ponašanja. |
| Je li kviz o obrascima refaktoriranja dovoljan? | Ne. Potvrđuje preduvjete, ali ne može li inženjer planirati i validirati promjenu. |
| Tko potvrđuje sadržaj? | Voditelj inženjerstva i viši inženjer koji poznaje kodnu bazu. |
| Što trening ne može popraviti? | Nedostatak alata za testiranje, tlak otpuštanja, nejasno vlasništvo i nedostatak vremena za radove održavanja. |
| Kako znaš da je uspjelo? | Novi, neviđeni slučaj s naslijeđenim kodom, bodovan prema dogovorenim kriterijima, s praćenjem stvarnog rada. |
1. Opišite problem s performansama
Započnite sa zadatkom: planirajte i validirajte ograničeno poboljšanje naslijeđenog koda. "Ograničeno" je važna riječ. Učenik odabire promjenu dovoljno malu da se završi i može reći što je unutar, a što izvan opsega.
Pomaže biti precizan s terminima. Martin Fowler opisuje refaktoriranje kao kontrolirana tehnika za poboljšanje dizajna postojeće kodne baze, sastavljen od malih transformacija koje čuvaju ponašanje. Izraz „očuvanje ponašanja“ je ono što razlikuje refaktoriranje od prepisivanja i to je ono što obuka mora učiniti vidljivim. Sama metafora tehničkog duga skovao ga je Ward Cunningham, a Fowlerova rasprava koristan je podsjetnik da se dug može preuzeti namjerno i razborito, tako da nije svaki neuredan modul pogreška koju treba ispraviti.
Knjiga Michaela Feathersa o naslijeđenom kodu zauzima isti stav o praksi. U opisu izdavača stoji da uči programere pisati testove koji osiguravaju ne mijenjaju nenamjerno aplikacijui staviti postojeći softver pod kontrolu bez potpunog prepisivanja.
Napišite izjavu o učinku u jednoj rečenici i neka je provjeri voditelj inženjeringa: „S obzirom na naslijeđeni modul i definirani cilj, inženjer predlaže ograničenu promjenu, dodaje testove koji određuju trenutno ponašanje, provodi promjenu u malim koracima i pokazuje da je ponašanje očuvano.“
2. Dijagnosticirajte nedostatke u učenju i kontekstu
Prije nego što išta izgradite, usporedite potreban zadatak s onim što vaše trenutne aktivnosti vježbaju i procjenjuju. Tri pitanja obično razlikuju prazninu u obuci od nečeg drugog:
- Koristi li trenutna praksa stvarni zadatak? Ako obuka pokriva obrasce refaktoriranja u slajdovima, ali nitko nikada ne mijenja netestirani kod, nitko nije vježbao zaštitno ponašanje. Ako je procjena test s višestrukim izborom o mirisima koda, ona mjeri prisjećanje.
- Što je kognitivna potražnja? U Bloomovoj revidiranoj taksonomiji, procjena je li promjena sigurna nalazi se na razinama analize i evaluacije, a dizajniranje plana i testova doseže razinu stvaranja. Usklađivanje aktivnosti s tim razinama obuhvaćeno je našim vodičem za usklađivanje aktivnosti učenja s Bloomovom taksonomijom.
- Stoji li na putu nešto osim vještine? Provjerite osoblje, alate i postupke. Ako izgradnja traje sat vremena, nitko neće često provoditi testove. Ako radovi na održavanju nikada nisu planirani, inženjeri će refaktorirati samo u tajnosti. Prijavite uzroke koji nisu povezani s obukom ljudima koji ih mogu popraviti.
3. Osmislite svrsishodnu pripremu i praksu
Nakon što znate koje praznine trening može popuniti, svakoj fazi dajte zaseban zadatak.
Priprema. Provjerite preduvjete kratkom dijagnostikom: kako funkcionira vaš okvir za testiranje, što je test karakterizacije i kako vaš tim pregledava i spaja. Učenje vlastitim tempom odgovara ovoj fazi. Provjera prisjećanja potvrđuje samo preduvjete.
Praksa. Koristite sustavne projekte refaktoriranja s jasnim oblikom. Započnite na malom, sigurnom uzorku, a zatim prijeđite na stvarni, ali ograničeni dio vlastite kodne baze. Gilded Rose kata je dobro poznata početna točka za prvi korak. To je README, koji održava Emily Bache, preporučuje pisanje testova prije promjene koda i vježbu definira kao praksu poduzimanja malih koraka, čestog izvođenja testova i poboljšanja dizajna malo po malo. Razuman slijed za svaki projekt je: definirati cilj i granicu, napisati testove koji bilježe što kod danas radi, mijenjati jednu stvar istovremeno, pokretati testove nakon svakog koraka i zapisati što ste naučili.
Povratne informacije. Povežite povratne informacije s odlukama, a ne s ukupnim rezultatom. „Iskoristili ste logiku popusta, ali vaši testovi pokrili su samo sretan put, tako da niste mogli primijetiti promjenu zaokruživanja“ korisnije je od „3 od 5“.
Unos instruktora uživo ili asinkroni pregled? Uživo unos dodaje najveću vrijednost kada je izbor dvosmislen, na primjer treba li stati i dodati test koji nedostaje ili nastaviti. Asinkroni pregled je dovoljan kada učenici uspoređuju svoj plan i testove s komentiranom verzijom za stručnjake. Mnogi timovi koriste oboje: prvo pripremu vlastitim tempom, a zatim vođenu sesiju o teškim slučajevima.
4. Razradite realističan primjer
Ilustracija. Voditelj inženjerstva trebao bi validirati slučaj i kriterije odgovora prije upotrebe.
Slučaj. Naslijeđena funkcija izračunava ukupan iznos narudžbe, uključujući popust, porez i pravilo dostave. Nema testova. Tim predlaže restrukturiranje cijelog modula za naplatu kako bi bio "čišći".
Zadatak. Učenik objašnjava što bi učinio, navodi dokaze koje bi prikupio i kaže koje su mu dodatne informacije ili podrška potrebne.
Prvi pokušaj. „Podijelio bih modul na tri servisa i premjestio logiku, a zatim provjerio brojke u pripremi.“ Polaznik je odabrao veliku promjenu i kasnu, ručnu provjeru. Ne postoji način da se utvrdi slažu li se stara i nova verzija oko rubnih slučajeva.
Povratne informacije i ponovni pokušaj. Recenzent pita što funkcija danas radi za praznu košaricu, popust koji ukupan iznos čini negativnim i slučaj zaokruživanja. Ponovni pokušaj traži od učenika da suzi opseg na jedno ponašanje i da kaže kako bi dokazao da se nije promijenilo.
Jači pokušaj. „Za sada bih ostavio strukturu modula netaknutom. Zabilježio bih ono što funkcija ukupne narudžbe vraća danas za skup ulaza, uključujući rubne slučajeve, kao testove. Zatim bih izdvojio izračun popusta u vlastitu funkciju, pokrenuo testove nakon tog jednog koraka i zaustavio se. Napomenuo bih da pravilo dostave ima ponašanje koje ne razumijem i pitao bih kolegu prije nego što ga se dotaknem.“ Primijetite da ovaj odgovor ograničava promjenu, prvo štiti ponašanje i imenuje ono što je nepoznato.
Zašto je svaki odgovor opravdan ili nepotpun. Svaki pokušaj procijenite prema odobrenim kriterijima, a ne prema preferencijama recenzenta. Prvi pokušaj može biti razuman dugoročni smjer, ali je nepotpun kao plan jer ne sadrži dokaze o očuvanom ponašanju. Jači pokušaj je malen, provjerljiv i iskren u pogledu nesigurnosti.
5. Procijenite kapacitete i planirajte prijenos
Dokaz sposobnosti je izvedba na novom slučaju naslijeđenog koda koji učenik nije vidio. Bodujte analizu rizika i dokaz da je ponašanje očuvano. Jednostavna rubrika koristi ljestvicu od 0 do 2 po kriteriju:
| Kriterij | Vidljivi dokazi |
|---|---|
| Izvršenje zadatka | Planira i validira ograničeno poboljšanje naslijeđenog koda te bilježi akciju i dokaze koji stoje iza nje. |
| Rasuđivanje | Objašnjava ograničenja, alternative i neizvjesnost te provjerava rizike i dokaze da je ponašanje očuvano. |
| Granice | Koristi odobrene postupke i traži pomoć kada informacije ili ovlasti nisu dovoljne. |
Sidra: 0 je odsutno ili nije potkrijepljeno, 1 je djelomično s relevantnim propustima, a 2 je potpuno i opravdano prema dogovorenim kriterijima. Kritične pogreške definirajte zasebno, poput promjene ponašanja bez testa koji bi je primijetio, tako da ukupni rezultat ne može sakriti jednu. Ova rubrika je prijedlog, a ne validirani standard spremnosti: prilagodite je s voditeljem inženjeringa i isprobajte je. Naš vodič za osmišljavanje interaktivne prakse s korisnim povratnim informacijama pokazuje kako napisati povratne informacije koje povezuju s odlukama.
Prijenos planirajte namjerno. Nakon vježbe, dajte svakom inženjeru mali, stvarni dug koji će riješiti s recenzentom ili napravite kratku retrospektivu nedavne promjene koja je nešto pokvarila. Provjerite prijenos nakon odgovarajućeg izlaganja stvarnom radu, a ne odmah nakon radionice.
Gdje interaktivna dostava pomaže
Interaktivni formati pomažu tamo gdje bi se svi trebali obvezati prije nego što vide grupu. U sesiji uživo, voditelj može pokazati kratki isječak naslijeđenog koda, zamoliti svakog inženjera da pošalje prvu promjenu koju bi napravio i kako bi dokazao da je sigurna, a zatim otkriti širenje prije rasprave. Isti uput može se izvoditi vlastitim tempom za pripremu. AhaSlides podržava interaktivno učenje i prelazak između isporuke uživo i vlastitog tempa. To je alat za prezentacije i učenje, a ne mjesto za pokretanje ili analizu koda, stoga pokrenite samo refaktoriranje u vlastitom okruženju. Provjerite bilo koju specifičnu funkciju autorstva, povratnih informacija ili izvještavanja na koju se planirate osloniti u odnosu na vlastiti tijek rada. Za smjernice o odabiru formata pogledajte naš članak o kada koristiti adaptivno, interaktivno i učenje uživo.
Mjeri što se promijenilo
Unaprijed odlučite što bi pokazalo da inženjeri mogu izvršiti zadatak. Usporedite kvalitetu analize rizika i dokaze o očuvanom ponašanju na neviđenom slučaju s početnom vrijednosti. Definirajte tko je uključen, nazivnik i vrijeme. Ako se rezultati poboljšaju, provjerite što se još promijenilo u istom razdoblju, poput novih alata za testiranje, brže izrade ili promjene vlasništva, prije priznavanja obuke.
Ograničenja koja mogu ostati
- Vrijeme je za radove na održavanju. Ako se rad na dugovima nikada ne planira, obučeni inženjeri i dalje nemaju gdje koristiti tu vještinu.
- Alati za testiranje. Bez upotrebljivog ispitnog pojasa ili brze izrade, male korake i česte provjere teško je održati.
- Pokrivenost slučaja. Jedan naslijeđeni slučaj pokazuje nekoliko vrsta rizika. Rezultat ne opisuje inženjersku procjenu općenito.
- Procjena kada ne treba refaktorirati. Neki kod je bolje ostaviti na miru, zamijeniti ga ili ukinuti, a ta odluka uključuje više od vještine.
- Prijenos. Izvedba u katama nije ista kao izvedba u produkcijskom modulu pod pritiskom isporuke.
Na vrijeme ih imenujte sponzorima i planirajte odvojene popravke. Obuka poboljšava ono što inženjer može planirati i dokazati. Ne stvara vrijeme niti alate.
Često postavljana pitanja
Što je projekt obuke za refaktoriranje?
To je strukturirana praksa na naslijeđenom kodu gdje inženjeri planiraju male promjene, štite postojeće ponašanje testovima, mijenjaju dizajn u malim koracima i pokazuju da se ništa nije pokvarilo.
Je li potpuno prepisivanje dobar način za učenje o tehničkom dugu?
Obično ne. Prepisivanje je veliko, teško ga je validirati i skriva vještinu koju želite razviti. Ograničena promjena s testovima koji bilježe trenutno ponašanje čini obrazloženje vidljivim.
Kako procjenjujete mogu li inženjeri sigurno refaktorirati?
Navedite novi slučaj s naslijeđenim kodom i ocijenite analizu rizika i dokaze da je ponašanje očuvano prema dogovorenim kriterijima. Kviz o obrascima refaktoriranja potvrđuje samo preduvjete.
Trebate li primjer kodne baze za obuku?
Trebate mjesto za sigurno vježbanje. Mnogi timovi počinju s javnom kata, a zatim prelaze na ograničeni dio vlastitog koda. Vaš voditelj inženjeringa trebao bi potvrditi da je kod prikladan.
Gdje započeti
Odaberite jednu malu, ponavljajuću vrstu naslijeđene promjene u svojoj kodnoj bazi. Napišite izjavu o performansama, neka voditelj inženjeringa validira slučaj i testove koji bi pokazali očuvano ponašanje te izradite rubriku s tri kriterija s ljestvicom od 0 do 2 i popisom kritičnih pogrešaka. Isprobajte je s malom grupom prije nego što je uvedete.
Da biste vidjeli kako bi se vježba donošenja odluka o refaktoriranju mogla izvoditi uživo s vašim timom i ponovno koristiti vlastitim tempom nakon toga, istražite AhaSlides.
