csapatszétszórás

Arra a melóra, amit én csinálok, 4 földrészen lehet jelentkezni. Ennek ellenére a szűkebb csapatból én vagyok az egyetlen, aki nem Tel Avivban dolgozik. A tágabb csapatból se sokan. Néha úgy tűnik, akár maradhattam volna Budapesten is. Egyszer megkérdeztem, hogy miért jó az hogy egy pár ember így a világban elszórva van, de a legtöbb (talán úgy 100 ember) egy városban. Hát, erre nem kaptam kielégítő választ :-) de gondoltam megosztanám mindenkivel a véleményemet erről a csapatszétszórásról általában:

A földrajzilag szétszórt csapatot sokan trendi dolognak tartják, pedig kommunikációs problémák lehetséges forrása. Nem cél, hanem egy probléma.

Például a gerriten, ircen keresztül pötyögni soha nem lesz olyan hatékony, mint odamenni valakihez és ledumálni  az egész problémát. Kicsit olyan, mintha a szervereidet plip-pel kötnéd össze, meg még egy csomót is kötsz rá, aztán csodálkozol hogy lassú meg rossz.

Amúgy ezt is lehet jobban csinálni, de pl az irc elég rendesen múlt századi technológia. Soha nem is irceztem mielött itt dolgoztam volna.

code review

A közhiedelem az, hogy a code review során a problémák nagy részét elkapjuk és kitekerjük a nyakát. Ez igaz is lehet egy bizonyos mértékig, de csak egy bizonyos mértékig. Nekem úgy tűnik, hogy a code review során gyakran új bugokat hozunk létre, az alábbi okokból:

• A reviewer személye mindig más. A mindig más személynek mindig mások a szempontjai. Például van olyan, aki azért dobja vissza a patch-et, mert nem final egy változód benne, van aki azért mert az és neki nem tetszik. "ha van kalapod, azért, ha nincs kalapod, akkor meg azért". Valljuk be, ez a final dolog még bölcsészek között is baszakodásnak számítana.
• A patch-ek szétválasztása és egyesítése tulajdonképpen kódolási tevékenység (azaz idővel és kockázatokkal jár) míg a végeredményhez semmilyen értéket nem tesz hozzá.
• Teljesen beteg vagyok attól, amikor valamit kétszer kell megcsináljak. Na és az még a jó eset :-) Ha elsőre jó volt, másodszor biztosan elcseszem.

Szóval a lefikázás után valami konstruktívat arról, hogy szerintem hogyan kellene használni a gerrit-et:

• Ha egy patch jobb állapotot hagy maga után, mint elötte, akkor had menjen. Lépjünk tovább, ne szarozzunk!
• Ha hiányzik belőle valami (de ugyanakkor attól még jó), akkor esetleg a reviewer hozzáírhat egy patchet és beküldheti, megmutathatja az eredeti patch szerzőjének, hogy ő még ilyesmire gondolt. Lehet vitatkozni, vagy örülni hogy "gyá télleg, köszi!"
• A fast forward policy csak több munkát hoz, gyakorlatban nem védett meg minket semmilyen hibától. Ezt a funkciót egyszerűen kijátszuk, mert nincs más választásunk.

Szóval én inkáb piacnak képzelnék el egy jól működő dolgot, mint vizsgabizottságnak. Lehet ezt is jól csinálni, csak mi nem úgy csináljuk. Megpróbáltam demózni az ötletet és egy pár hétig egy-egy embernek végignéztem a patch-setét egyenként ellenőriztem és ha jó volt egyből be is mergeltem. Szépen haladtunk. Mindenki örült, de aztán senki sem kezdte utánozni a módszert :-(

Amúgy a gerritet továbbra sem komállom, mert:

• A gerrit üzenetei suttyók - pl ezért én soha senkinek nem adok -1-et, mert az olyan bunkó szöveg, hogy inkáb fogalmazok valami barátibbat levélben.
• A felhasználói felülete ótvar. Ki hitte volna hogy GWT-ben is lehet ocsmány weboldalakat szerkeszteni? :-)
• A használhatósága csekély, pl keresés nagyon hiányzik belőle, de a saját lezárt patcheimet sem tudom átnézni benne.