Jó zsaruk és rossz zsaruk

Minicube

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast nyolcadik epizódja.

Van az a mondás, hogy a code review-t ötből négy ember élvezi. Nyilván, hiszen az ötödik az, aki ellenben úgy érzi, hogy szívatják, mert épp az ő kódját nézik át.

Természetesen a fenti arányok nem minden cégre érvényesek, mert mások és mások a szokások, sőt! Van ahol maga a kód review sem bevett szokás.

Na de mi is ez az egész? Miért van ilyesmire szükség? A kód review során az érintettek- akik általában a csapatból, vagy az alkalmazást magukénak vallók közül kerülnek -, ki vadul nekiesnek a beküldött pull requestnek. Ez a pull request a verziókövetőben lehet külön branch, fork, akármi. Itt sokan sokféle dolgok után kutatnak, jó vagy éppen rossz példákat követve. A célja az egésznek az lenne, hogy mások is lássák a kódot, megértsék azt, ha pedig kifogásolnivalót találnak benne, akkor azt jelezzék az illetőnek.

Sajnos sokan elkövetik azt a hibát, hogy szemre checkstyleozzák a kódot, vagy egyéb statikus analizáló szimatával mennek végig rajta, felemlegetve az összes kimaradt final kulcsszót, hiányzó entert és hasonlót. Ezzel az a baj, hogy akármilyen jól is gépel az illető, aki épp átnézi a kódot és akármilyen gyorsan is észleli ezeket a hibákat, sosem fog a gépek nyomába érni. Ezért ami ilyet ellenőrízni lehet automatikusan, azt ellenőrízni is kell, sőt mi több… ha bármi gond van, törjön az a build!

Na de tegyük fel nincs ilyen kollégánk a cégnél. Akkor továbbra is a cél, hogy mások is lássák a kódunkat. Na de minek? Nincs ezeknek jobb dolga? Ők is kódolnak és még a határidők is szorosak, nyomjatok már rá az approve gombra és vehessem fel a következő taskot, nem igaz? Van az a bizonyos mondás, hogy “the only way to go fast is to go well” azaz az egyetlen mód, hogy gyorsan fejlesszünk, az az, ha jól csináljuk azt.

Tehát pontosan azért van erre szükség, hogyha a következő task, amit valaki más felvesz és a mi általunk patkolt kódrészleteket érinti, akkor ne azzal teljen el a fél napja, hogy megpróbál rájönni mi az és 0. lépésként átnevezgessen, refaktorájon. Helyette amikor odajut, akkor egy olyan kóddal találkozzon, amit már vagy ő maga is látott, vagy mások is látták és megértették. Ha pedig nem értették meg elég gyorsan, akkor nem magukban keresték a hibát, hanem szóvá tették és javítotva lett.

A mostani csapatomban már megállapítottuk, hogy én vagyok a rossz zsaru, a másik budapesti backend fejlesztő pedig a jó zsaru, ugyanis én vagyok az, aki köti az ebet a karóhoz és sokkal szigorúbb, ha bármi nem tetszik a kódban, míg ő hamarabb elengedi a dolgokat. Nyilván itt nem egyéni preferenciára kell gondolni, mert a kód review nem ennek a helyszíne. Persze meg lehet mondani, hogyha valami szerinted másképp jobb lenne, de érvek nélkül sokat nem ér.

Az egyik leggyakoribb érv, amivel védekeznek az esetleges kommentjeimmel szemben az a “dehát a kódban máshol is így van”. Persze, mert akkor mikor az készült még nem voltam itt, hogy megcsináljam és azóta se jutottam el oda. Nyilván nem ezt fogom válaszolni, meg rövid is az adás, hogy belekezdjek a monológomba, de maradjunk csak az úgynevezett boys scout rulenál. A cserkészeknél volt egy ilyen szabály, hogy a portát mindig jobb állapotban hagyd, mint ahogy érkeztél.

Ez igaz a kódra is. Lehet, hogy aki előtted beletúrt szemét módon nem javította ki azt az elírást, nem emelte ki azt a 8x másolt kódrészletet egy helyre. Viszont ha Te ránézel érzed, hogy az ott nincs jól, így ha tele is van a kód ilyenekkel, akkor se fogd arra, hogy máshol is úgy van. Az esetek többségében hamarabb kijavítasz dolgokat, mintsem végeznél a kommentháborúval. Energiát spóroltál vele és még jobb is lett a kód. Win-win.

Nyilván ez nem mindig ilyen egyszerű, mert gyakran nem csak véleményeket, de egókat is ütköztetünk a review kommentekben, amiből nehéz jól kijönni. Ilyenkor érdemes bevonni valaki mást is, aki függetlenül tud döntést hozni az ilyen esetekben. Persze a legjobb lenne az, ha ettől mentesíteni tudnánk a kódot. Ahogy mondtam, rendes érvek nélkül sokat nem ér, de néha nehéz ezeket megtámogatni, hiszen sokszor szubjektív témákban megy a vita, lévén ugyanazt a problémát rengeteg módon meg lehet közelíteni és oldani is.

Sajnos igen tipikus hiba, hogy hatalmas pull requesteket gyártunk, amik még commitok mentén sincsenek szétválogatva. Na ilyenkor szokták gyorsan rávágni, hogy hibátlan, approve. Nyilván nem az, de akkora munka lenne végigmenni rajta, hogy senki sem akarja venni a fáradtságot. A legszörnyűbb kódok így kerültek be hozzánk is. A hatalmas csomagolás mélyén ott lapultak azok, amik felett elsiklottunk.

Persze ahogy a szoftverfejlesztésben és az életben úgy általában itt sincs szent grál. Tehát ellehetünk ilyesmi nélkül. Az is teljesen jól működhet, hogyha a csapatban nincs dedikált review, de cserébe párokban dolgozunk. Emiatt végig lesz egy második szem, aki már az elején tud szólni, ha valami a kódban csak nekünk tiszta, de neki nem az és valószínűleg másnak sem lesz az. Ahogy a bugokat is minél hamarabb fogjuk meg, annál kisebb lesz a kár, úgy igaz ez a kódban talált érthetetlen részekre is. Ha már az írás során felfedezzük ezeket, akkor nem kell több review körön átverni, nem kell x alkalommal újrabuildelni a szerveren, saját gépen és hamarabb eljut oda, hogy tesztelhető legyen.

A lényeg: A kódot továbbra sem gépeknek, hanem embereknek írjuk. Ha már a review alatt sem értjük meg mit is csinál az adott kódrészlet, akkor ez szép lassan elkezd gyűlni és gyűlni, arról nem is beszélve, hogy a review akkor van, amikor még az illető fejlesztő képben van, emiatt sokkal gyorsabban tud intézkedni, mint az aki x hónap múlva odamegy a kódhoz és csak pislog, hogy mi is történik.

Lehet ez a valaki pont mi leszünk x hónap múlva és pontosan ugyanannyira lesz számunkra is kaotikus, mint a review többi szereplőjének. Akkor fogjuk megérteni, hogy miért is szóltak be amiatt, mert az elnevezéseink félrevezetőek, átláthatatlan az egész és még sorolhatnám.

Ez volt a minicube podcast, ha tetszett az adás, akkor nézzétek meg az app.letscode.hu-t is, ahol kicsit közelebbről nézzük meg a kódot. Ha pedig írnátok nekem, akkor azt a [e-mail] mail címre tudtok. Találkozunk legközelebb, sziasztok!

---

Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.