Egy csapat örököl egy számlázási modult, amelyet senki sem ért teljesen. Nincsenek tesztjei, amelyek megvédenék a meglévő viselkedést. Javasolnak egy sprintet a „tisztítására”, és a terv az, hogy a magot egy új struktúrában írják át. Senki sem tudja megmondani, honnan tudhatná, hogy az új verzió továbbra is helyesen számlázza ki az ügyfeleket.
Ez egy szemléltető forgatókönyv, nem dokumentált incidens. Azt a rést írja le, amelyet egy refaktorálási képzési projektnek kell betöltenie: olyan mérnökök, akik látják, hogy a kód rendezetlen, de még nem tudnak korlátozott fejlesztést tervezni, és kimutatni, hogy a viselkedés megmaradt.
Ez az útmutató mérnöki képzési vezetők és mérnökmenedzserek számára készült. Kitér arra, hogyan kell leírni a teljesítményproblémát, diagnosztizálni a hiányosságokat, a tervezés előkészítését és gyakorlatba ültetését, egy esettanulmány kidolgozását, valamint annak értékelését, hogy a készségek átvihetők-e a valós munkába. A tervezés betanításáról szól. A programban található kódot, teszteket és szabályokat vezető mérnököknek kell validálniuk a saját rendszereden.
Mi az a refaktorálási képzési projekt?
A refaktorálási képzési projekt egy strukturált munka hagyományos kódon, amelynek célja a képességek fejlesztése és a kód fejlesztése. A tanulók egy apró, korlátozott változtatást terveznek, tesztekkel védik a meglévő viselkedést, kis lépésekben javítják a tervet, és bizonyítékokat mutatnak be arra, hogy semmi sem romlott el. A kód egyre jobb lesz, és ami még fontosabb, a mérnökök a valós technikai adósságokon gyakorolják a szükséges ítélőképességet.
Gyors tények
| Kérdés | Rövid válasz |
|---|---|
| Mi a feladat? | Tervezzen meg és validáljon egy korlátozott, örökölt kódfejlesztést. |
| Mit érsz el? | Kockázatelemzés, és bizonyíték arra, hogy a meglévő viselkedés megmaradt. |
| Jó képzési projekt egy átfogó átírás? | Általában nem. Elrejti a gyakorolt készséget, és megnehezíti a megőrzött viselkedés kimutatását. |
| Elég egy kvíz a minták refaktorálásáról? | Nem. Megerősíti az előfeltételeket, de nem azt, hogy egy mérnök képes-e megtervezni és validálni egy változtatást. |
| Ki ellenőrzi a tartalmat? | Egy mérnöki vezető és egy vezető mérnök, aki ismeri a kódbázist. |
| Mit nem old meg a tréning? | Hiányzó tesztszerszámok, kioldási nyomás, nem egyértelmű tulajdonjog és nincs idő karbantartási munkákra. |
| Honnan tudod, hogy működött? | Egy új, eddig nem látott, örökölt kódon alapuló esettanulmány, amelyet egyeztetett kritériumok alapján értékeltek, és amely a valós munka nyomon követését is magában foglalja. |
1. Írd le a teljesítményproblémát
Kezdjük a feladattal: tervezzünk meg és validáljunk egy korlátozott, örökölt kódfejlesztést. A „korlátozott” szó a lényeg. A tanuló egy elég kicsi változtatást választ a befejezéshez, és meg tudja mondani, mi esik bele és mi nem.
Segít a kifejezések pontos használata. Martin Fowler a refaktorálást úgy írja le, mint egy ellenőrzött technika egy meglévő kódbázis tervezésének javítására, apró, viselkedésmegőrző transzformációkból áll. A „viselkedésmegőrző” kifejezés az, ami megkülönbözteti a refaktorálást az átírástól, és ezt kell a betanításnak láthatóvá tennie. Maga a technikai adósságmetafora Ward Cunningham alkotta meg, és Fowler érvelése hasznos emlékeztető arra, hogy az adósságot tudatosan és körültekintően is fel lehet vállalni, tehát nem minden rendetlen modul jelent javításra szoruló hibát.
Michael Feathers könyve a hagyományos kódról ugyanezt a gondolatot képviseli a gyakorlattal kapcsolatban. A kiadó leírása szerint a könyv olyan tesztek írására tanítja a fejlesztőket, amelyek biztosítják a következőket: nem akaratlanul változtatják meg az alkalmazást, és hogy a meglévő szoftvereket teljes átírás nélkül ellenőrzés alá vonják.
Írd le a teljesítménynyilatkozatot egy mondatban, és kérd meg egy mérnöki vezetőt, hogy ellenőrizze: „Egy örökölt modul és egy meghatározott cél alapján a mérnök korlátozott változtatást javasol, teszteket ad hozzá, amelyek meghatározzák a jelenlegi viselkedést, kis lépésekben hajtja végre a változtatást, és bemutatja, hogy a viselkedés megmaradt.”
2. A tanulási és kontextuális hiányosságok diagnosztizálása
Mielőtt bármit is építenél, hasonlítsd össze a szükséges feladatot azzal, amit a jelenlegi tevékenységeidben gyakorolsz, és értékeld. Három kérdés általában megkülönbözteti a képzési hiányosságokat valami mástól:
- A jelenlegi gyakorlat a valódi feladatot használja? Ha a képzés a diákon található minták refaktorálását is magában foglalja, de senki sem változtat teszteletlen kódon, akkor senki sem gyakorolta a védelmi viselkedést. Ha az értékelés egy feleletválasztós teszt a kód szagairól, akkor a felidézést méri.
- Mi a kognitív igény? Bloom átdolgozott taxonómiájában a változtatás biztonságosságának megítélése az elemzés és az értékelés szintjén történik, míg a terv és a tesztek megtervezése a létrehozás szintjén. A tevékenységek ezen szintekhez való illesztését az útmutatónk tárgyalja. tanulási tevékenységek Bloom taxonómiájához való illesztése.
- Vajon a képességen kívül valami más is akadályozza? Ellenőrizd a személyzetet, az eszközöket és az eljárásokat. Ha a build egy órát vesz igénybe, senki sem fog gyakran teszteket futtatni. Ha soha nem ütemeznek karbantartási munkálatokat, a mérnökök csak titokban fogják refaktorálni a hibákat. A képzésen kívüli okokat jelentsd azoknak, akik meg tudják oldani azokat.
3. Céltudatos felkészülés és gyakorlás megtervezése
Miután megtudta, mely hiányosságokat tudja a képzés pótolni, adjon minden szakasznak külön feladatot.
Készítmény. Ellenőrizd az előfeltételeket egy rövid diagnosztikával: hogyan működik a tesztelési keretrendszered, mi az a jellemzési teszt, és hogyan értékeli és vonja össze a csapatod a feladatokat. Az önálló tempójú tanulás alkalmas erre a szakaszra. Az előfeltételek ellenőrzése csak az előfeltételek teljesülését erősíti meg.
Gyakorlat. Használj szisztematikus, egyértelmű alakú refaktorálási projekteket. Kezdj egy kis, biztonságos mintán, majd haladj a saját kódbázisod egy valós, de korlátozott részére. A Gilded Rose kata egy jól ismert kiindulópont az első lépéshez. A README fájlt Emily Bache tartja karban. azt javasolja, hogy a kód módosítása előtt írjon teszteket és a gyakorlatot apró lépések megtételének, a tesztek gyakori futtatásának és a terv lépésenkénti fejlesztésének gyakorlásaként keretezi. Minden projekthez egy értelmes sorrend a következő: határozd meg a célt és a határokat, írj teszteket, amelyek rögzítik, hogy mit csinál a kód ma, változtass egy dolgot egyszerre, minden lépés után futtasd a teszteket, és írd le, mit tanultál.
Visszacsatolás. Kapcsold a visszajelzést döntésekhez, ne egy összpontszámhoz. A „Kiemelted a kedvezménylogikát, de a tesztek csak a szerencsés utat fedték le, így nem vehetted észre a kerekítés változását” hasznosabb, mint a „3 az 5-ből”.
Élő oktatói közreműködés vagy aszinkron értékelés? Az élő bevitel akkor ad a legtöbb értéket, ha a választás nem egyértelmű, például, hogy leállítsák-e és hozzáadjanak-e egy hiányzó tesztet, vagy folytassák-e. Az aszinkron áttekintés elegendő, ha a tanulók összehasonlítják a tervüket és a tesztjeiket egy jegyzetekkel ellátott szakértői verzióval. Sok csapat mindkettőt alkalmazza: először az önálló ütemű felkészülést, majd egy facilitált ülést a nehéz eseteken.
4. Dolgozz ki egy valós példát
Szemléltető példa. A mérnöki vezetőnek használat előtt validálnia kell az esetet és a válaszkritériumokat.
Az eset. Egy hagyományos függvény kiszámítja a rendelés végösszegét, beleértve a kedvezményt, az adót és a szállítási szabályt. Nincsenek tesztjei. Egy csapat azt javasolja, hogy a teljes számlázási modult átalakítsák, hogy „tisztább” legyen.
A feladat. A tanuló elmagyarázza, mit tenne, idézi a gyűjtött bizonyítékokat, és elmondja, milyen további információra vagy támogatásra van szüksége.
Első próbálkozás. „Három szolgáltatásra osztanám a modult, és áthelyezném a logikát, majd a stagingben ellenőrizném a számokat.” A tanuló egy nagy változtatást és egy késői, manuális ellenőrzést választott. Nincs mód annak megállapítására, hogy a régi és az új verzió megegyezik-e a szélsőséges esetekben.
Visszajelzés és újrapróbálás. A felülvizsgáló megkérdezi, hogy mit csinál a függvény ma üres kosár, negatív összegű árengedmény és kerekítés esetén. Az újrapróbálkozás során a tanulónak szűkítenie kell a hatókört egyetlen viselkedésre, és el kell mondania, hogyan bizonyítaná, hogy az nem változott.
Egy erősebb próbálkozás. „Egyelőre békén hagynám a modulstruktúrát. Tesztként rögzíteném, hogy mit ad vissza a rendelésösszeg függvény ma egy bemeneti halmazra, beleértve a szélső eseteket is. Ezután kinyerném a kedvezményszámítást a saját függvényébe, lefuttatnám a teszteket az adott lépés után, és leállítanám. Megjegyezném, hogy a szállítási szabálynak van olyan viselkedése, amit nem értek, és megkérdezném egy kollégámat, mielőtt hozzányúlnék.” Figyeljük meg, hogy ez a válasz korlátozza a változást, először a viselkedést védi, és megnevezi az ismeretlent.
Miért védhető vagy hiányos az egyes válaszok? Mindegyiket jóváhagyott kritériumok alapján ítéld meg, ne a bíráló preferenciái alapján. Az első próbálkozás lehet egy értelmes hosszú távú irány, de tervként hiányos, mivel nem hordoz bizonyítékot a megőrzött viselkedésre. Az erősebb próbálkozás kisebb, ellenőrizhető és őszinte a bizonytalansággal kapcsolatban.
5. Képességfelmérés és a terv átadása
A képesség bizonyítéka egy új, örökölt kódon elért teljesítmény, amelyet a tanuló még nem látott. Pontozd a kockázatelemzést és a viselkedés megőrzésére vonatkozó bizonyítékot. Egy egyszerű értékelőlap kritériumonként 0-tól 2-ig terjedő skálát használ:
| Kritérium | Megfigyelhető bizonyítékok |
|---|---|
| Feladat végrehajtása | Megtervez és validál egy korlátozott örökölt kódfejlesztést, és rögzíti a műveletet és a mögötte álló bizonyítékokat. |
| Érvelés | Elmagyarázza a korlátokat, alternatívákat és bizonytalanságot, valamint ellenőrzi a kockázatokat és a viselkedés megőrzésére vonatkozó bizonyítékokat. |
| Határok | Jóváhagyott eljárásokat alkalmaz, és segítséget kér, ha az információ vagy a felhatalmazás nem elegendő. |
Horgonypontok: 0 hiányzik vagy nem támogatott, 1 részleges, releváns hiányosságokkal, és 2 teljes és a megállapodás szerinti kritériumok alapján indokolt. A kritikus hibákat külön kell meghatározni, például a viselkedés megváltozását olyan teszt nélkül, amely észrevehető lett volna, így az összesített pontszám nem rejtheti el azokat. Ez a rubrika egy javaslat, nem pedig egy validált készültségi szabvány: adaptálja egy műszaki vezetővel, és tesztelje. Útmutatónk a következőkhöz: interaktív gyakorlatok tervezése hasznos visszajelzésekkel bemutatja, hogyan kell döntésekhez kapcsolódó visszajelzést írni.
Tervezd meg tudatosan az átadást. A gyakorlat után adj minden mérnöknek egy kis, valós adósságot, amit egy felülvizsgálóval megbeszélhet, vagy készíts egy rövid visszatekintést egy nemrégiben történt változtatásra, ami elrontott valamit. Ellenőrizd az átadást a valós munkával való megfelelő találkozás után, ne közvetlenül a workshop után.
Ahol az interaktív közvetítés segít
Az interaktív formátumok segítenek, ahol mindenkinek el kell köteleznie magát, mielőtt találkozik a csoporttal. Egy élő ülésen a facilitátor megmutathat egy rövid részletet a korábbi projektből, megkérheti az egyes mérnököket, hogy küldjék be az első módosításukat, és azt, hogyan bizonyítanák annak biztonságosságát, majd a megbeszélés előtt felfedhetik a részleteket. Ugyanez a feladatsor önálló tempóban is futtatható a felkészüléshez. AhaSlides támogatja az interaktív tanulást és az élő és az önálló tempójú előadás közötti váltást. Ez egy prezentációs és tanulási eszköz, nem pedig kód futtatására vagy elemzésére szolgáló hely, ezért magát a refaktorálást a saját környezetedben futtasd. Ellenőrizd azokat a konkrét szerzői, visszajelzési vagy jelentéskészítési funkciókat, amelyekre a saját munkafolyamatodban támaszkodni tervezel. A formátumok kiválasztásával kapcsolatos útmutatásért lásd a cikkünket a ... témában. Mikor alkalmazzunk adaptív, interaktív és élő tanulást?.
Mérd meg, mi változott
Előre döntsd el, mi mutatná, hogy a mérnökök képesek elvégezni a feladatot. Hasonlítsd össze a kockázatelemzés minőségét és a megőrzött viselkedés bizonyítékait egy nem látott esetben egy alapértékkel. Határozd meg, hogy kik tartoznak bele, mi a nevező és mi az időzítés. Ha az eredmények javulnak, ellenőrizd, hogy mi változott még ugyanebben az időszakban, például új teszteszközök, gyorsabb build vagy tulajdonosváltás, mielőtt jóváírnád a képzést.
Maradhatnak korlátok
- Karbantartási munkák ideje. Ha az adósságkezelési munkát soha nem ütemezik be, a képzett mérnököknek még mindig nincs hol kamatoztatniuk a képességeiket.
- Tesztelő eszközök. Használható tesztkábelezés vagy gyors összeszerelés nélkül nehéz fenntartani a kis lépéseket és a gyakori ellenőrzéseket.
- Eseti lefedettség. Egy korábbi eset néhány kockázattípust mutat be. A pontszám nem írja le általánosságban egy mérnök ítélőképességét.
- Annak megítélése, hogy mikor nem kell refaktorálni. Vannak kódok, amiket jobb magára hagyni, lecserélni vagy kivonni a forgalomból, és ez a döntés többet igényel, mint pusztán szakértelmet.
- Átadása. A katában nyújtott teljesítmény nem ugyanaz, mint egy produkciós modulban nyújtott teljesítmény nyomás alatt.
Nevezd meg ezeket a szponzoroknak időben, és tervezz külön javításokat. A képzés javítja a mérnökök tervezési és bizonyítási képességeit. Nem teremti meg az időt vagy a szerszámokat.
Gyakran Ismételt Kérdések
Mi az a refaktorálási képzési projekt?
Ez egy strukturált gyakorlat hagyományos kódon, ahol a mérnökök apró változtatásokat terveznek, tesztekkel védik a meglévő viselkedést, apró lépésekben módosítják a tervet, és bebizonyítják, hogy semmi sem romlott el.
Jó módszer a teljes átírás a technikai adósság megismerésére?
Általában nem. Egy átírás nagyszabású, nehezen validálható, és elrejti a fejleszteni kívánt készséget. Egy korlátozott változtatás, olyan tesztekkel, amelyek rögzítik az aktuális viselkedést, láthatóvá teszi az érvelést.
Hogyan értékeli, hogy a mérnökök biztonságosan képesek-e refaktorálni?
Adjon meg egy új, hagyományos kódon alapuló esetet, és pontozza a kockázatelemzést, valamint a viselkedés megőrződésére vonatkozó bizonyítékokat a megállapodás szerinti kritériumok alapján. A refaktorálási mintákról szóló kvíz csak az előfeltételeket erősíti meg.
Szükséged van egy minta kódbázisra a képzéshez?
Szükséged van egy helyre, ahol biztonságosan gyakorolhatsz. Sok csapat egy nyilvános katával kezd, majd a saját kódjuk egy korlátozott részére tér át. A mérnöki vezetődnek kell megerősítenie, hogy a kód megfelelő-e.
Hol kezdjem
Válassz ki egy apró, ismétlődő, örökölt változtatást a kódbázisodban. Írd meg a teljesítménynyilatkozatot, kérd meg egy mérnöki vezetőt, hogy validálja az esetet és a teszteket, amelyek a megőrzött viselkedést mutatják, majd készíts egy háromkritériumú rubrikát 0-tól 2-ig terjedő skálával és a kritikus hibák listájával. Teszteld le egy kis csoporttal, mielőtt bevezetnéd.
Ha szeretnéd megtudni, hogyan futtathatsz le egy refaktorálási döntési gyakorlatot élőben a saját csapatoddal, és hogyan használhatod fel utána saját tempódban, fedezd fel a következőt: AhaSlides.
