2013. április 19., péntek

code review (anti)patterns

Egyik nap néhány munkatársammal beszélgettünk arról, hogy hogyan haladunk és egyetértettünk abban, hogy ahogyan a code review történik, az nem csak hogy nem segít a minőség javításában, de néha teljesen hülye hibákoz is vezet. Én a hiba okát abban látom, hogy a reviewer soha nem tesztel. Túl sok dolga van. A reviewer minnél hamarabb túl akar lenni az egészen, ezért megkeresi az első hibát, lefikázza és otthagy. Ez általában a commit comment, amit átírsz és majd a későbbi patchek során hetekkel később kiderül hogy mégse volt az olyan rossz.
Mindenesetre a patch írói az első verziót szokták tisztességesen letesztelni. A második verziót talán. Mindegy, X idő és Y review után már a tökük televan ezzel a patch-el, szánják-bánják hogy hozzákezdtek és a végül elfogadott patch-en könnyen lehet hogy a kutya se futtatott teszteket, ha ugyan vannak még benne. A manuális tesztekről inkáb ne is beszéljünk :) Az nyilvánvalóan csak az első pár patch-nél történt és a véglegesnél nagy valószinűséggel nem. Gyakran van az, hogy a végleges verziót már marhaságnak tartom, de mindegy, csak menjen már.
(Szakirodalom: Boris Vian: Venyigeszú és a plankton)

Szóval erre halmoztunk fel pár zavaró megoldást amit felváltva és kombinálva használunk. Ezek nagyban növelik a káoszt, de kicsit javítják a teljesítményt, minket persze az utóbbi érdekel.

  1. Küldj patchet akkor, amikor a csapat meetingen van. Tréfi, de ez van. Szükséged van valakire nyilván aki elfogadja neked gyorsan, de a legjobb ha nem adsz időt a trolloknak, meg a hatszáz rebaselést is elkerülöd.
  2. Spameld a reviewereidet.

    A legegyszerűbb kommentbe írogatni hogy "ping". Rossz esetben blokkolva leszel, ekkor változtass e-mail címet. (gúgliban a gipsz.jakab+1@gmail.com pl műxik) Naponta vagy másnaponta egy email nekem elegendő középútnak tűnik egy kultúrált úriember és egy nigériai tábornok között, de persze volt már aki teljesen kiakadt és sikítozni kezdett. Nem lettem érte lecseszve, a CÉG majomként kezeli a szoftverfejlesztőket. Ez szerintem sem áll távol a valóságtól.
  3. Ha csinálsz junit teszteket, soha ne pakold ugyanabba a patchbe, mint amibe a kódot. A patch-sor végén elég lesz. Ha eljutsz odáig, akkor bekerül, ha nem akkor meg nem tart fel. De tipikusan egy olyan tényező, ami csak feltart. Az egyik oka annak, hogy nem igazán vannak junit tesztjeink az az, hogy mindig az kerül utoljára hogy legalább valamennyire haladjunk.
  4. Racionalizáj: dobd ki a reviewereket egy adott létszám felett! Az inkatívakat mindenképpen, mert rájuk csak várnak. Az akadékoskodókat csak ha lehet.

    Próbáld ki, írj egy közös akármit (levelet a nagymamának, főnöködnek, a köztársasági elnöknek vagy a halál pöcsének) úgy hogy 8 embernek egyet kell értenie minden szavával és senki nem akar még hozzátenni valamit. Amit valaki hozzá akar tenni, azt más majd el akarja venni. 8 ember nem tud egyetérteni valamiben. (Szakirodalom: 12 dühös ember)
  5. Újra ugyanazt

    Teljesen működő megoldás mégegyszer más címen vagy akár csak más ID-val elküldeni ugyanazt mégegyszer és esetleg valaki mást kérni review-re. Lebukás-veszély persze van, de szerencsére úgyse tudják megjegyezni a nevemet.
  6. Szép dolog maintainernek lenni, de haszontalan

    Ez megint egy érdekes csavar a történeten, de egy rémegyszerű dolgot nem sikerült sehogy sem átverekednem a többi maintaineren, senki sem merte bevállalni. Egy idő után eldobtam a patch-et, úgy gondoltam elég időt pazaroltam rá. Pár hónappal később egy új kolléga küldte el tejesen ugyanazt a változtatást. Csak leellenőriztem és be is lett mergelve.
  7. Dobd ki az ablakon.

    Ezt sajnos gyakran csinálom, de ha 2-3 hétig a noszogatás ellenére se csinál senki semmit, akkor kidobom a patchet. Ez a legtöbb reviewernek nem probléma. Néhányan szoktak csak felháborodni hogy "de hát jó volt". Lehet hogy jó volt, de sehova se haladtunk vele. Rémesen sok időt elvesztegettünk rá és végül sehova se jutottunk, de még mennyi időt elvesztegethettünk volna arra, hogy sehova se jutunk a végén? Egy újraírás talán csak 5 perc. Teszttel együtt egy óra :D De ez semmi ahhoz képest hogy mennyi baszakodás lesz vele.

Szóval a rendszer elég egyszerű lenne, de valahogyan mindig kisebb-nagyobb csalásokra kényszerül az ember. Nem egzakt tudomány, inkáb számvitel és politikatudomány mint matek és fizika. Valami ilyen lehet földhivatalban dolgozni.

Tudom kurvára utáltok amiért képtelen vagyok a marketinglófaszt elénekelni nektek, de gondoltam ez valamivel hasznosabb lehet :)

2013. április 1., hétfő

Atom / RSS feed test tool

Van a w3c feed validátor, ami király, de a leghétköznapibb RSS feedre is azt mondja, hogy törött. Sajnos igaza van, de nem állhatunk meg tökölni amikor kiderül hogy az internet fele sz*r, hanem megtanuljuk szépen tolerálni a hülyeséget. Másrészt a technikai minőségéről semmit nem mond, csak a formátumáról.


Szóval csináltam egy saját feed test eszközt, amivel a legutóbbi teszt szintén elég szomorú (de legalább szines) eredményeit hoztam ki. Tessék ehun van e. A kis edit boxba kell bedobni az RSS/Atom feed-ed címét és kidobja az eredményt. Nem túl felhasználóbarát felület. Ha gondolod próbáld ki a saját feed-jeiden és szólj vissza ha valamivel nem értessz egyet!