Történt már veled olyan, hogy a kódolás közben elakadtál és segítséget kértél egy tapasztaltabb kollégától, de ahogy magyaráztad neki a kódodat úgy válaszoltad meg magadnak a saját kérdéseid?
Bevallom őszintén velem már előfordult és ilyenkor mindig cikinek éreztem, hogy lényegében feleslegesen zavartam meg a kollégámat. Ha kicsit hátradöltem volna és elolvastam volna a kódot, magamtól is megtaláltam volna a helyes válaszokat.
Néha nagyon bele tudunk merülni a kódolásba, ilyenkor bekerülünk a "zónába" és csak írunk és írunk… de lényegében alig gondolkozunk azon, hogy mit miért is teszünk. Csak akkor kezdjük el jobban szemügyre venni a sorainkat, amikor valamit nem értünk, hogy miért nem működik, vagy amikor egy kis manó meg nem szólal a fejünkben, hogy "azért ezt csak nem így kéne csinálni", vagy "biztos van ennél elegánsabb megoldás".
Ilyenkor hátra kell dőlni, kilépni a zónából és megkeresni a régi gyerekkori barátunkat, a jó öreg gumikacsát. Gumikacsát?! Igen! Nem kötelező gumikacsa legyen, megteszi bármilyen tárgy ami egy kis időre a kollégánk lesz és csakúgy mint egy code review keretén belül, elmagyarázzuk neki, hogy mit miért tettünk.
Ilyenkor születnek azok az "Aha!" gondolatok, amikor lényegében saját magunk code review-oljuk a kódunkat. Ez a módszer nem helyettesíti a tényleges code review-t, mert ez a kód mégis a saját gyerekünk és mint minden jó szülőknek, a mi kódunk lesz számunkra is a legszebb és a legjobb, de nem árt egy kicsit nekünk is szemügyre venni még mielőtt másokkal is átnézetnénk a kódunkat.
A code review vagy peer review egy olyan szoftver minőségbiztosítási módszer, amelynek során egy vagy több személy átnézi egy szoftvernek a részleges vagy teljes kódbázisát. Legalább az egyik személy más kell legyen mint a kód szerzője.
A code review célja a kód minőségének és karbantarthatóságának javítása, a szoftverhibák felderítése, a tudás átadása kollégák közt, illetve a kollektív felelősségérzet erősítése.
Egy jó tanács: ha irodában dolgozol több kollégával, előtte jobb ha szólsz nekik.
A miértre a válasz egyszerű. A szoftverfejlesztés komplex folyamatok összegzése, amit nagyon nehéz egy idő után követni. Amikor már messze elkalandoztunk és már úgy érezzük, hogy mi se értjük pontosan, hogy mit miért is csinálunk, akkor segít ha az elejétől kezdjük újra átgondolni, hogy mi is a célunk és mit és hogyan valósítottunk meg eddig.
Annál jobb metódus nincs is mint, hogy megpróbáljuk elmagyarázni a szoftver jelenlegi működését egy olyan "kollégának" aki semmit sem tud a szoftverről.
Neki egészen részletesen el kell magyarázni a projektet és ilyenkor lényegében magunknak is magyarázunk. Mi más felelne meg ennek a legjobban mint egy olyan "kolléga" aki aztán tényleg semmit nem tud a kódról (például egy gumikacsa)? Figyeljük meg, hogy amint sorról sorra magyarázzuk a kódot, egyre inkább kezd tisztulni a kép a saját fejünkben is.
Ha leblokkoltál és már tényleg nem tudod, hogy hogyan tovább, hívd segítségül a jó öreg gumikacsát, ő megoldja majd a problémát. Egy próbát megér.