Szükség van-e a kód felülvizsgálatára? Nem vizsgáljuk felül a kódot egyidejűleg a fejlesztéssel? Ha már rendszeresen használom a refaktorálást, akkor mi értelme újra ellenőrizni a kódot?
Sok kérdés merülhet fel egy fejlesztői csoportban a kódellenőrzésekre hivatkozva. De még a kérdéseknél is rosszabbak az aggodalmak vagy a félelmek ("ha a kódomat ellenőrzik, a munkám tönkremegy!"). Először is azzal kezdjük, hogy meghatározzuk, mi a kódellenőrzés (kódellenőrzés).
A Code Review meghatározása
Kezdjük egy olyan forgatókönyvből, amelyben agilis keretek között dolgozunk, és a különböző lehetőségek között válasszuk a Scrum-ot. Ennek a posztnak nem célja, hogy elmélyüljön e módszertanok működésében. Bár lehetséges, hogy a jövőben többet fogok róluk beszélni, az Internet tele van velük kapcsolatos információkkal; Kifejezetten Javier Garzás blogját ajánlom.
Létre kell hozni egy kezdeti keretrendszert a szoftverfejlesztés megközelítésének megkereséséhez. A Scrumban a "fejlesztői egység" a felhasználói történet, az időegység pedig a sprint.
Képzeljük el, hogy egy 4 fejlesztőből álló csapatnak egy sprint alatt el kell osztania több felhasználói történet fejlesztését. Képzeljük el, hogy egy egyéni fejlesztőnek (nevezzük Luis-nak) hozzárendelik az X felhasználói történetet (például: "Adatmaradási réteg létrehozása").
A kódellenőrzés az a folyamat, amelynek során a csapat többi tagja együtt áttekinti Luis adott felhasználói történet megvalósítását, ötleteket adva a továbbfejlesztésére, esetleg átalakítására, esetleges hibák, architektúra hibák felfedezésére, a tesztek lefedettségének hiányára bizonyos esetekben, és egy sor egyéb felmerülő dolog.
Vonakodás ...
Legyünk közvetlenek: „bonyolult” profilok bővelkednek szakmánkban. Anélkül, hogy túl részletes részletekbe menne, bizonyos fejlesztők nem állnak kritikával szemben, még kevésbé módosíthatják az általuk elkészült és elméletileg működő kódot. Ha bármelyik olvasó ebbe a csoportba tartozik, a következő kérdéseket tenném fel neki:
- Könnyen érthető a kódod másoknak, mint te?
- Maga is képes lenne megérteni ezt a kódot pár év múlva?
- A kód fejlesztésekor figyelembe vett-e MINDEN olyan tényezőt, amely befolyásolja vagy befolyásolhatja a rendszert?
- Ha feltűnő hibát fedezett fel valaki más kódjában, nem gondolja, hogy szakemberként felelős a kijavításért? Ebben az esetben nem jobb az ilyen hibák mielőbbi észlelése?
A kód gyűjtése. A kód nem az enyém
Valójában, amikor üzleti projekten dolgozunk, programozunk egy kódot, amelyet a jövőben is jó néhány fejlesztő fejleszt, fejleszt és karbantart. Úgy gondolom, hogy egy ilyen területen nincs értelme a kód egyéni tulajdonjogáról beszélni, éppen ellenkezőleg.
A kód közös tulajdonjoga arra ösztönzi az agilis csapatot, hogy vállalja a felelősséget a teljes szállított rendszer működéséért. Nem szabad ujjal mutatni a tettesekre, ha valami nem működik, vagy azt sugallni, hogy "nem voltam ott" vagy "nem voltam ott". Azt mondanám, hogy valami ilyesmi nyilvánvaló ... de egyáltalán nem az.
A tapasztalatok azt tanították, hogy a kód felülvizsgálata a leghatékonyabb módszer az ideál elérésére.
A folyamat
A kódellenőrzés folyamata akkor kezdődik, amikor egy fejlesztő feltölti, vagy már feltöltötte a központi adattárba (feltételezzük, hogy Git vagy hasonló verzióvezérlő eszközt használunk) a hozzárendelt előzmények megvalósításához kapcsolódó összes változást. felhasználó.
A csapat többi tagja (példánkban a másik három fejlesztő), vagy legalább 50% -ot megmaradó (a példában minimum 2) ellenőrzi a rendszerhez hozzáadandó kód minden változását, és hozzászólások útján Barátságos és informális környezetben kétségeiket terjesztik bizonyos döntésekkel, fejlesztési javaslatokkal kapcsolatban, és természetesen „remek felbukkanást” nyújtanak az esetlegesen zseniális vagy különösen sikeres ötletek kapcsán. Ezeknek az észrevételeknek arra kell összpontosítaniuk, hogy lefedjék az általam ebben a bejegyzésben felvetett kérdéseket, és az előnyök számosak és nyilvánvalóak:
- Fedezze fel az eszközöket, az API-kat, a probléma kezelésének módjait ... amelyeket nem ismertünk
- Szerezzen átfogó ismeretet a rendszerről (nemcsak az általam kifejlesztett részekről)
- Hozzon ki külső nézőpontokat, és tegyen fel kérdéseket, amelyeket a vezető fejlesztő esetleg figyelmen kívül hagyott
- Javítsa a minőséget és az olvashatóságot. Néha egy olyan kód működése, amely nagyon nyilvánvaló lehet az alkotója számára, mások számára nem annyira nyilvánvaló
- A várva várt "kódközösség" elérése
Természetesen a csapat többi tagjának nem minden megjegyzése lehet pontos, és ez rajtunk múlik Az egész csapat konszenzusra jutni a felülvizsgálat befejezése után meghozandó intézkedésekről. Általában mindig lesznek változások, amelyeket alkalmazni kell. A jelenlegi cégemnél természetesnek vesszük, hogy a „Kód felülvizsgálata” után mindig lesz egy „Változások a kód felülvizsgálata után” feladat, és ezeknek a feladatoknak a becslését mindig hozzáadjuk a teljes felhasználói történethez. Valójában soha nem zárunk be (Kész) egy felhasználói történetet, amíg át nem esett a kód felülvizsgálata.
A kódellenőrzés során az Egost parkolva kell hagyni. Nem vagyunk versenyben a legfényesebb programozó megtalálásáért, csak azt akarjuk, hogy termékünk a legjobb minőségű legyen.
Az eredmény
Nagyon szeretem ezt a képletet (egy atlassiai videóban fedeztem fel, amelyet nem sikerült újra megtalálni):
- G: a termelésben talált hiba hibájának egyéni bűntudata
- R: az érintett kódot áttekintő személyek száma
Ezért arra következtetünk, hogy ha egy kódot senki nem néz át, csak egy ember felelős lesz a gyártás meghibásodásáért. Míg ha az egész csapat áttekinti a kódot, akkor a hiba az egész csapatra kiterjed. Nem értük el a keresett "kódex kollektív tulajdonságát"?
Eszközök
Kódellenőrzés történhet úgy, hogy összehozza a csapatot egy szobába, vagy egy erre a célra létrehozott eszközzel. A piacon több, nyílt forráskódú és kereskedelmi forgalomban is működő Code Review. Ebben a linkben közülük több is szerepel. Személyesen dolgoztam a Crucible by Atlassian céggel, amely remekül integrálódik az Atlassian többi csomagjába (JIRA a feladatkezeléshez, Stash mint Git kódtár) stb., És lehetővé teszi a beszélgetések elindítását kódsorból, blokkból, általános megjegyzések stb.:
Személyes tapasztalatom
Meg merem mondani, hogy sokkal jobb szakember vagyok, mivel egy olyan csapat tagja vagyok, amely folyamatosan használja a kódellenőrzéseket. Nem csak mindenre, amit megtanulnak, amikor a kódot tesztelik, vagy amikor át kell néznie mások kódját, ezáltal olyan kritikus és elemző szellem alakul ki benned, amelyet más körülmények között nem használnánk ilyen egyértelműen.
Van még egy „kényelmetlenebb” tényező, amelyet elmondhatunk: ez az, hogy előre tudva, hogy a kódot felül fogják vizsgálni, jobban programozunk:). Bizonyos sértések vagy elsajátított gyakorlatok, amelyekről biztosan tudjuk, hogy nincsenek helyesek, de amelyeket kissé lusta elkerülni, mindenképp sarokba szorulnak, amikor kódlátogatás van a láthatáron.
Következtetések
Éppen tegnap fejeztem be egy projektet, amelyen 11 hónapja dolgozom (valójában ma kezdem a vakációmat:)), ez idő alatt 75 kódellenőrzéssel készültem. Úgy gondolom, hogy ez messze a legmagasabb minőségű termék, amelyet eddig szállítottam, és teljesen rágyújtanék a kezem érte. Biztos vagyok benne, hogy a többi projektfejlesztő pontosan ugyanúgy gondolkodik, mint én. A „Code Reviews” nélkül soha nem tudtunk volna elérni ilyen magas színvonalat, még távolról sem.
Próbálkozzon a kódismertetőkkel, soha nem tér vissza.