Korábban írtam arról, hogy hogyan vezessük be a Code Review intézményét. Most arról szeretnék írni, hogy mi az amit én fontosnak tartok, és hogy hogyan érdemes felépíteni az ellenőrző listánkat.

Kód és kód között van különbség

Első körben érdemes meghatározni, hogy milyen kód is az, amit nézünk. Ugyanis összehasonlíthatatlanul mást fogunk nézni egy valamilyen programozási nyelven írt kódnál, mint egy olyan kódnál, ami nem algoritmus leírására való. Ilyen pl. a HTML vagy a CSS/SCSS. Aztán ott vannak az olyan fájlok, amik befolyásolják ugyan a működést, de nem futtatható kód található bennük. Ilyenek a különböző config állományok, például services.yaml, router.json stb.

Végül lesznek olyan kódok, amiket inkább nem nézünk át. Például aki fejlesztett már Drupal oldalt, az tudja, hogy akár egy komplett adminisztrációs rendszert is össze lehet kattintani vele, amely beállításokat aztán fájlba exportálva verziókezelés alá helyezhetünk. Ember legyen a talpán, aki egy ilyen generált fájlt átnéz.

Az én TOP hármas listám programozási nyelven írt kódokra vonatkozik.

Idő és tér

Az sem mindegy, hogy a Code Review térben és időben hogyan történik. A leghatékonyabb módja természetesen a pair-programming, amikor egymás mellett ülve közösen alkotjuk meg a kódot. Van ahol push előtt történik meg a kód átnézése, ami szintén hatékony tud lenni. A skála végén a legrosszabb és legkevésbé motiváló megoldás helyezkedik el, amikor pull request-eket két-három nap, esetleg hét után néz végig valamelyik kolléga. Ez utóbbit szokták open source körökben használni, de csak azért, mert ott ez az, ami megoldható. Én nem látom értelmét annak, hogy egy légtérben, egyazon projekten dolgozó kollégák egymás kódját ne egy közös (2 fő) megbeszélés formájában nézzék át.

1. Mindenki számára legyen érthető a kód

Ha programozási nyelven írt kódról van szó, akkor nálam első körben az érthetőség az amit nézek és a kollégákat is erre kérem. A kódszervezés és a függvény/változó nevek azok, amik ide tartoznak. Általában már az első külső szemlélő is kiszúrja azokat a neveket, amik a kód készítése közben tök logikusak voltak, de később már időt kell eltöltenie azzal, hogy megértse valaki. Mit tárol a tdb változó, miért node nevet viseli az a tömb amibe a kapcsolódó tartalmak vannak, és miért nodes az amiben mindig biztosan csak egy elem van, bár korábban úgy volt, hogy több is lehet benne. Ne aggódjunk, két hónap rendszeres gyakorlással már mi is képesek leszünk ilyen külső szemlélőként a saját kódunkat vizsgálni és a legtöbb hibát kiszűrni.

Nagyon erős meggyőződésem, hogy az oktatásban kondicionálják arra a programozókat, hogy minél érthetetlenebb kódokat gyártsanak a sok “Mit csinál ez a kód” és hasonló feladatokkal. Aztán ezeket az egysoros förmedvényeket elnevezik elegáns megoldásnak.

Én nem töltenék nagyon sok időt azzal, hogy leírást készítsek arról, hogy milyen az érthető kód, mivel nagyon nehéz azt jól és időtállóan megfogalmazni. Ehelyett inkább a fejlesztők közötti gyakori kommunikációt javaslom (ld. idő és tér). Gondoljunk bele, hogyan fogalmazzuk meg, hogy mikor jó ternary operatort használnunk? Mert van számos eset amikor kifejezetten könnyíti a kód olvashatóságát, de van amikor teljességgel olvashatatlanná teszi a kódunkat.

2. Tartsuk magunkat és a többieket az előre megbeszéltekhez

Amennyiben megbeszélünk valamilyen szabályt vagy megoldást, akkor ahhoz tartsuk magunkat és követeljük is meg másoktól azok betartását. Csak nagyon indokolt és kivételes esetben térjünk el attól. Fontos, hogy ezeket a kódokat jelöljük meg, és térjünk rájuk vissza a retrospektíven. (Retrospektív alatt én azt értem, amikor átbeszéljük, hogy mit csináltunk jól, min kell változtatnunk, mit tanultunk, ezeket rögzítjük, belőlük teendőket generálunk és ezeket a teendőket végre is hajtjuk.) Ha kell, módosítsunk a szabályon vagy tegyük át a kisebb prioritású szabályok közé, vagyis ne nézzük többet. Ne felejtsük a “kivétel erősíti a szabályt” egy badarság, egy félrefordítás. Minden egyes kivétel gyengíti a szabályt és a betört ablak elv igenis működik.

Fontos, hogy ha valaki folyton valamilyen szabályt szeretne szegni, akkor nagyon valószínű, hogy nem érti az adott szabály fontosságát. Ilyenkor érdemes leülni és külön energiát fordítani arra, hogy megértse, miért fontos az a szabály a csapatnak.

Az egyik legviccesebb Code Review élményem az volt, amikor egy megjegyzésem beküldése után szinte azonnal felhangzott a szomszéd szobából az “Óóó basszus, tudtam, hogy pp szólni fog ezért” kiáltás. Igazából ennek örültem, mert azt jelentette számomra, hogy már nagyon közel vagyunk ahhoz, hogy az adott kolléga ne kövesse el többet azt a hibát, hisz tudja, érti a fontosságát, csak még egy kicsit gyakorolnia kell azt. Egyben ez a példa rámutat arra is, hogy mennyivel hatékonyabb lett volna vele együtt átnézni a kódot.

Ne legyünk restek és adjuk meg a kollégáknak a gyakorlás lehetőségét, szóljunk mindig, ha találunk valami olyat ami nem a megbeszélteknek megfelelő.

Természetesen van olyan, amikor a kolléga jól megfontolt szándékból, helyesen választ valamilyen másik megoldást, mint amit megbeszéltünk. Ilyenkor érdemes az egész csapat elé vinni az indokokat és a megoldást, hogy mindenki tanulhasson belőle.

3. Legyen tesztelhető a kód

Bár ezt a pontot is bepaszírozhatnánk az előbbi alá, én mégis kiemeltem, hisz manapság már nem nagyon érdemes olyan kódot gyártani, ami nem tesztelhető. Természetesen erre mondhatnánk, hogy azért van olyan, amit nem lehet automatán tesztelni, csak manuálisan. Azonban én úgy gondolom, hogy ez az állítás inkább úgy igaz, hogy jelenleg nincs módszerünk és eszközünk arra, hogy az ilyen típusú dolgokat teszteljük. Ha hosszú távban gondolkodunk, akkor ezt a problémát meg kell oldanunk.

A legkézenfekvőbb megoldás, hogy keresünk módszert és eszközt. Ez viszont nem egyszerű, hisz kutatást és gyakran egyedi fejlesztést igényel. Ez drága lesz, és lehet, hogy egy-egy projekt nem is fogja tudni megfinanszírozni, ezért külön projekteken átívelő keretet érdemes rá igényelni a menedzsmenttől.

A másik módszer nehezebb, de megfelelő gyakorlattal szinte csodákat tudunk elérni vele. Nagyon sokszor van ugyanis, hogy le tudunk választani részeket a függőségeinkről, és ezáltal a kód jelentős részét tesztelhetővé tehetjük.

Volt olyan csapat, akiknél amikor életszerű példán keresztül próbáltam meg megmutatni a mock-olást sehogy sem sikerült. Tíz feletti kódrészletet hoztak, ahol mindig a függőségek leválasztásával kezdtem, így sose maradt olyan függőség, amit mockolni kellett volna. Valahogy mindig kiderült, hogy az a nagyon fontos függőség igazából nem is kell annyira, ha egy picit átszervezzük a S.O.L.I.D. elvek mentén a kódot.

Ez volt az én TOP 3 listám a Code Review esetében. A Te listád TOP szekciója hogy néz ki? Beszéltetek róla a kollégákkal? Ha nem, akkor beszéljetek és után osszátok meg velem, ha lehet.