Amennyiben elkészítetted a könnyen felállítható fejlesztői környezetet, a Code Review kidolgozása következhet. A megfelelő Code Review ugyanis alkalmas arra, hogy biztosítsa az egységes és megfelelő minőségű kódot számodra. Ebben a bejegyzésben a Code Review bevezetésének hogyanjára koncentrálok. Itt ugyanis van négy veszélyes hiba, amelyek elkerülése maximalizálja a siker lehetőségét. Azzal, hogy mit érdemes nézni egy Code Review-n egy következő bejegyzésben fogok foglalkozni.

1. Érzelmek figyelmen kívül hagyása

Talán nem is kell mondanom, hogy fejlesztők körében, akik napi munkájuk során elsősorban a logikai és az értelmi képességeiket használják, óhatatlanul háttérbe szorul az érzelmek tudatos kezelése. Ezért aztán gyakran előfordulnak kisebb sértődések, de akár komolyabb konfliktusok is egy-egy Code Review során. Ezek leggyakoribb forrása az, hogy a fejlesztő magára veszi az általa készített kódot ért kritikát, és személyes sértésként fogja fel azokat.

Tisztában vagyok azzal, hogy az igazi megoldást e téren a **megfelelő önismeret **kialakításával és a soft skillek fejlesztésével lehet elérni, de erre nem mindig van idő és lehetőség a szervezeten belül. Ilyenkor én gyors megoldásként mind kommunikációs szinten, mind hozzáállásban megpróbálom leválasztani a kódról annak fejlesztőjét.

Van egy mantraként ismételgethető négysoros, amit ilyenkor előveszek.

Nem rólad szól a vélemény. Nem a Te kódodról szól a vélemény. Nem az általad írt kódról szól a vélemény. A kódról szól a vélemény, amit közösen alkotunk.

Emellett természetesen érdemes figyelni arra, hogy milyen megfogalmazásokat használnak a fejlesztőink, és bátorítani őket, hogy a megfelelő megfogalmazásokat használják. Például az “A kódod azért hibás, mert…” megfogalmazás helyett az “Ez a kód azért hibás, mert..” megfogalmazást használják. Vagy legyenek esetleg kedvesek, és a kevésbé karcos, és megengedőbb “Ez a kód nem a legjobb ebben az esetben, mert…” formulával fejezzék ki véleményüket. Esetleg a konstruktív “Szerintem jobb lenne úgy, hogy…” javaslattal mozdítsák előre a párbeszédet.

Fontos megérteniük, hogy most egy közös alkotás részesei és a vélemények, amik elhangzanak gazdagabbá, jobbá teszik az együtt készített programot.

2. Tökéletességre való törekvés

Az érzelmeken kívül, az egyik legnagyobb változás, amikor az ember elkezd csapatban dolgozni, hogy sok-sok dolog mellett fel kell adnia a tökéletességre való törekvését. Nagyon nehéz ugyanis csapatban kialakítani egy olyan workflowt és szabályrendszert, amit mindenki tökéletesnek talál. Ez azért van, mert minden fejlesztő az élete során más más problémaszettel találkozik, ezért más lesz az általa megalkotott tökéletes megoldás. Ezek a tökéletes megoldások az adott fejlesztő tapasztalatának kontextusában lesznek csak tökéletesek és igen nehéz - megfelelő önismeret híján - elfogadni vagy elképzelni, hogy létezik más tökéletes megoldás is.

Ezt a gordiuszi csomót én úgy szoktam átvágni, hogy biztosítom arról a fejlesztőket, hogy én nem szeretném vitatni senki megoldását sem, de szükségünk van egy mindenki számára elfogadható közös nevezőre. Felhívom a figyelmüket, hogy most nem a legjobb, hanem a mindenki számára elfogadható megoldást keressük; nem többet, de nem is kevesebbet.

Ez természetesen azt is jelenti, hogy ha valami valaki számára nem elfogadható, akkor keresnünk kell helyette valami mást, ami mindenki számára elfogadható lesz.

3. Túl sok szabály

Ha a fenti két hibát elkerültük, akkor még mindig van egy olyan nehézség amivel meg kell küzdenünk. Ez a szabályok betartása és betartatása. A Code Review ugyanis nem más, mint a közösen megalkotott alapelvek érvényesítése, biztosítása. Ha nagyon sok szabályunk van, akkor óhatatlanul lesznek olyanok, amik kimaradnak, elfelejtődnek. Aztán az így kimaradt szabályok az “á múltkor is kihagytuk ezt” felkiáltással egyre ritkábban és ritkábban kerülnek betartásra, majd végül elfelejtődnek. Ez a folyamat azután addig eszkalálódhat, hogy magát a Code Review intézményét rengeti meg. Ezért szoktam azt mondani, hogy kevesebb szabály jobb ilyen esetben. Nézzük meg mit tehetünk, hogy a szabályok számát minél alacsonyabban tartsuk.

Első és nagyon fontos összetevő, hogy csak a humán beavatkozást igénylő szabályok számát kell korlátozni, az automatizált, gépi ellenőrzéseknél nem kell számolni a pszichológiai tényezőkkel, mint monotonitás tűrés, kedélyállapot vagy a kajakóma. (Természetesen a gépek öntudatra ébredése esetén itt is számolnunk kell majd ezzel a tényezővel, de szerencsére ez még messze van. :))

A szabályok számát tehát úgy tudjuk csökkenteni, ha minél több szabályt tudunk automatizálni, és rábízni a CI szerverünkre.

Nézzük meg, hogy hogyan redukáljuk azokat a szabályokat, amik mindenképpen emberi beavatkozást igényelnek. A szabály részletes leírását tegyük a Wikibe. Jó helyen lesz itt a szabály neve, célja, példa kódokkal kiegészített részletes magyarázata.

Amire a Code Review-hoz szükségünk lesz az egy ellenőrző lista, ami a szabályok neveit fogja tartalmazni. Menjünk végig a szabályokon és súlyozzuk azokat. Már egy két fokozatú skála is elég lesz nekünk. Jelöljük meg a “nagyon fontos” és a “szuper lenne ha” szabályokat, majd rendezzük a listát fontossági sorrendbe, hogy a legfontosabbak legyenek legelöl.

Amennyiben ötnél több szabály esik a legfontosabbak közé, akkor ezek közül válasszunk ki ötöt, amivel az első héten vagy sprintben fogunk foglalkozni. Ezután fokozatosan bővítsük a szabályokat egészen addig, amíg flottul nem megy az összes top szabály betartása. Ezután térjünk át a többire. Legyen az a megállapodásunk a csapattal és a menedzsmenttel, hogy a top szabályokat minden körülmények között betartjuk, a többi szabályt pedig akkor, ha nem jelent jelentős pluszt a fejlesztési időbe.

Ezt a fokozatosságot aztán használhatjuk akkor is, ha egy új kollégát, pláne egy juniort szeretnénk integrálni a csapatunkba.

4. Kommunikáció hiánya

Van még egy nagyon fontos eleme a bevezetésnek, amin nem érdemes spórolni. Az előbb említett ellenőrző lista, annak betartatása és a megkövetelt Code Review nem fog önmagában minőségi javulást eredményezni. Sőt, a lehető legrosszabb amit tehetsz, hogy az internetről összevadászott ellenőrző listának a betartását követeled meg a fejlesztőidtől. Akkor se vagy sokkal előrébb, ha a cég vezető fejlesztője egyedül alkotja meg azt.

Fontos ugyanis, hogy a fejlesztők értsék, elfogadják és magukra nézve kötelezőnek tartsák azt. Ezért a lehető legtöbb fejlesztőt érdemes bevonni a folyamatba, ami során kialakulnak a Wiki oldalak és az ellenőrző lista. Mindenki érezze azt, hogy hozzátett valamit a szabályrendszerhez vagy legalábbis azt, ha akarna, akkor tudna rajta változtatni.

Teremtsük meg a teret, ahol a fejlesztők együtt gondolkozhatnak és fogalmazhatják meg a cég mit ért nagyszerű kód alatt.

Amennyiben bizalmat szavazol nekem és engem bízol meg ezzel a feladattal, akkor én is a fejlesztőkkel közösen fogom megalkotni a szükséges dokumentumokat.

Ezeket az együtt kialakított szabályokat azután rendszeresen vizsgáljuk felül. Kezdetben hetente vagy sprintenként, majd legkésőbb félévente tegyük meg ezt. Fontos ez utóbbi féléves ciklus, mert a kezdeti gyakori retrospektíveken nagyon hamar el fognak fogyni a módosítási igények, és úgy érezhetjük majd hammisan, hogy megalkottuk a végleges szuperszabályzatot, amihez többé nem kell nyúlni.

Neked mi a véleményed erről? Nálatok mik a top szabályok? Oszd meg velem és én is le fogom írni egy következő bejegyzésben, hogy nálam mik azok.