Miért kell kirúgni a fenébe az összes Rambo kódert?

Pontosan azért, hogy az elmúlt néhány napnyi munkát meg lehessen spórolni. Igen, nagyon nem jó az a rendszer, amit jelenleg tovább kell vinni (a cseréjéig). Nagyon összetákolt, és tele van a vakvilágba össze-vissza hivogató dolgokkal.

Na az ilyenen a legrosszabb a Rambo kóder, aki azt hiszi, hogy ő a faszagyerek, ő egymaga mindent megold, másnak lófasz tapasztalata sincs és különben se ért hozzá. Ő tudja, ő megoldja jól. Igen, aztán elfelejt szólni róla és 1-2-3 hónappal később derül ki egy alaposabb átnézés során, hogy valójában adott egy pofont a szarnak, mert bár javított egy dolgot, 2-t eltört és 3 másik rendszert is tönkretett, mert az is azokból az adattáblákból dolgozik (a miérteket most hagyjuk), amelyet rendkívül frappáns módon lecserélt egy _new utótagúval.

Na az ilyen kóder menjen a picsába vagy menjen one man projektezni.

( pityulaman1983 v | 2012. 06. 18., h – 15:54 )

Már láttam olyat, aki hallott olyanról, aki tudott olyat, akit Te mondasz :D

Nekem a mottóm az, hogy azt kapod, amit kérsz, de általában figyelmeztetek előtte, ha fájni fog.

Ugye elmondom, hogy logfeldolgozásnál semmi értelme naponta 30 napra visszamenően dolgozni. Minden nap az aznapit elvégzed, a 30 napos végeredményt a részeredményekből kiszámolod.

Az elképzelésem azon bukott meg, hogy a megbízó nem akart tárolni semmit. Most naponta mindent újra kiszámolunk.

A legdurvább kicseszés időnként azt adni, amit kér, de ha sokat ugrál a megbízó, akkor leszállítom.

( zolti v | 2012. 06. 18., h – 18:29 )

Megértelek, de ez így elég egyoldalú.

Tény, de arról nem tehetek, hogy ilyen apróságokról, minthogy lecserél három táblát baszott megkérdezni bárkit is. Mert ő ért hozzá. (Eleve hogy lehet így lecserélni és miért nem a régieket fejlesztette tovább? -- semmi gond nem lett volna a legacy cuccokkal) Ráadásul azt sem vezette végig teljesen az adott rendszeren belül. Tudta jól, hogy létezik még a másik rendszer is, amely össze van növesztve azzal, amelybe belenyúlt.

Igazából szinte leszartam volna már, hogy mit csinál, ha egyszer csak bumm nem lépett volna le a francba.

De amúgy hozhatnék példát az előző munkahelyemről is. Pl. ott is volt egy arc, aki úgy döntött, hogy "neki nem tetszik a doWork függvény neve" - azt kellett implementálni a gyermekosztályban - és ezért inkább a fél keretrendszert elkezdte áttúrni. Hogy ezzel _mindenki_ más munkáját eltörte, az más kérdés.

Szimplán itt lett ma elegem végleg az ilyen egyszemélyes "én mindenhez értek" rohamhadseregekből, akik képtelenek csapatban dolgozni. Holnap írhatom át egy másik nagyobbacska művét, mert ott is megjavított 1-2 dolgot, csak épp egy igen fontos funkciót eltüntetett.

(Az mennyit árul el neked, hogy a nevezett jóembertől a vége felé kérdeztem, hogy dolgozott-e már csapatban, amire egy rendkívül lesajnáló, flegma "saaajnos" választ kaptam?)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( uid_4263 v | 2012. 06. 20., sze – 08:25 )

Használjatok review toolt (pl. gerrit), meg automatikus teszteket (ci, pl. jenkins), rengeteget segítenek a kódminőség javításában, fenntartásában.

--
http://neurogadget.com/

Aaahahahahhaaahhhahhhh... Orulok, hogy a legacy kodoknak mar egy resze egyaltalan elkezdett atszivarogni SVN-be es mar legalabb csak a mindenfele _new _2, 3, 4 stb. suffixu fajlokat kell kitakaritani, nem az osszes letezo szemetet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Arra céloztam hogy jó esetben minden product-hoz (vagy repóhoz, komponenshez, nevezzük ahogy szeretnénk) tartozik egy senior (vagy csoportvezető), aki visszadob olyan változtatásokat amik olyanok amiket fent emlegettél, így el lehet kerülni a rossz commit -okat. :) És ebben nagy segítség a gerrit.

--
http://neurogadget.com/

Igen, egy nagyobbacska sw fejlesztő cégnél ez így is nézne ki. De ez itt nem az. És nekünk nem "product"-unk van, hanem szolgáltatás kifele, valamint rendszerek befele. És ezekkel a rendszerekkel azért nincs annyi meló külön-külön, hogy egész csapat kelljen rájuk.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az általad leírt dolgok egy az egyben illenek ránk is, igaz, a fent vázolt dolog nem alkalmazható 1 kóderre. Viszont ahol már legalább ketten dolgozunk, ott a review elválaszthatatlan része a munkafolyamatnak, oda-vissza, és alig van olyan change ami elsőre bekerülhet.

--
http://neurogadget.com/