Az egész fejlesztés alapelve a magabiztosság, minden tekintetben! Ha nem vagy magabiztos a dolgodban, dolgozd ki alaposabban, teszteld le jobban, vitasd meg mással. Bízz a saját munkádban.

Ha nincs meg a magabiztosság, vagy nem mersz valamihez hozzányúlni, akkor ott a csíra, a posvány csírája. Ki kell irtani, mert ha elharapódzik, akkor csak nagyon fájdalmasan és drágán lehet utána megszüntetni. Minél hamarabb fedezünk fel egy problémát, annál olcsóbb javítani, és javítani kell! Minél tovább van halogatva, annál drágább lesz a javítása, lásd MDB. Aki ismerte az MDB-t, az tudja, hogy halálra ítélt technológia volt. Igen, tudom, hogy én csináltam... Attól még szar volt. :) Ma már olyan szinten ráépült a rendszer, hogy nem lehet kivenni, és megoldani. Csak közel olyan drágán, mint a rendszer teljes újraírása.

A legrosszabb példa: ha van egy kód, modul, amihez „nem lehet hozzányúlni", akkor az egy idő után belerohad a kódba. Ha ezekre más modulok épülnek, akkor egyre nehezebb és nehezebb lesz a dolgot karbantartani.

Ennek számos következménye van:

  • nem akar majd ahhoz a feladathoz senki hozzányúlni
  • ha egy olyan munka van, ami az adott területet használja, érinti, akkor azt is kerülni fogják a kollégák
  • ezeken a területeken nem szívesen fejlesztünk, és nem szívesen akarunk majd az ügyfél változtatásoknak eleget tenni
  • ez rombolja a morált, és így a szervezetet is
  • nem leszünk magabiztosak, nem tudunk majd minden esetben pontos becslést és jó munkát kiadni, vagy legalábbis az lesz az érzés, hogy nem tudom, jó-e

Ez olyan érzés lesz a kollégának, hogy tudom, el van rontva, de már késő. „Egyszer majd valamikor újraírom."

Soha.

Ha van ilyen munka valahol a kódban, és utána beleakadunk, esetleg rátámaszkodunk, akkor már bevallani is nehezebb lesz — magunknak és másoknak is. Még akkor is, ha nem te csináltad. „Miért nem szóltál, ha láttad korábban?" — ez további rossz érzéseket kelt a kollégában. Ami azt az érzést növeli benne, hogy majd legközelebb jobban csinálom, majd a következő feladatnál, vagy inkább majd a következő modulnál, vagy a másik projektben, vagy majd a következő munkahelyen...

Lehet érezni a frusztráltságot? Ha egy kolléga nem érzi magát biztonságban a kódban, akkor a szervezet sincs abban. Nem lehetnek olyan részek, amelyek erodálják a kódot, így a kollégák motivációját és végeredményben a terméket és a szervezetet is erodálják.

Sajnos, ha egyszer lát valaki ilyen gányt, akkor a következő esetben már könnyebben megy, hiszen „egyszer belefért" vagy „ebben is így van megoldva", stb. És nem csak közvetlen úton szaporodik tovább a gány, hanem már copy-paste-tel vagy mintaként szolgál másoknak, tehát mutálódva szaporodik. Így a gány más helyeken is felüti a fejét. Ez spirálba vezet. A végeredmény: egy olyan kódbázis, amin a dolgozók egyre kevésbé akarnak dolgozni, mindenki másik projekten akar dolgozni.

Ebből adódik a tévhit, hogy mindenkinek kell egy kis levegőváltozás, más projekt, más terület. Hülyeség, nagyon nagy hülyeség. Ha valaki élvezi a munkáját, és egy területen egyre jobb és jobb, egyre több és több eredményt ér el, akkor egyre büszkébb és büszkébb lesz a munkájára! Ha valaki egy olyan területen dolgozik, amiben lelkes, új ötletei vannak, folyamatosan jó benne, és ez éreztetve is van vele, akkor jól érzi magát a bőrében. Na ekkor mondd neki azt, hogy dolgozz más munkán. Nem fog neki tetszeni, abban biztos lehetsz.

A munkahelyváltások egyik legnagyobb oka az IT szektorban, hogy a dolgozók más területre vágynak, mert amiben most dolgoznak, az már nem elég.

A gány kód nem csak komplett modul lehet, hanem az interfész, egy osztály, vagy akár csak egy függvény is. Sőt, van, hogy a függvény neve a gány: nem egyértelmű, és nem tudja senki, mire jó, vagy mit fog csinálni. „Do", „Calculate", „Recalc". Recalc what? Írd le!

Együtt kell küzdeni a gány ellen, és ez mindenkinek jó. Ha egy tapasztalt dolgozót veszítünk el — amellett, hogy egy barát megy el —, fontos az is, hogy a helyére betanítani valakit olyan mértékű idő- és pénzkiesés, amelynek töredékéből lehetett volna a kódbázis egyes részeit javítani, ha azt időben felismerik.

Ehhez kapcsolódik az a gondolat is, hogy 5 évente a programozók állománya a világon megduplázódik. Valószínűleg ez lassulni fog 2035 környékén. De addig ez azt jelenti, hogy a programozói társadalom fele 5 évnél kevesebb tapasztalattal rendelkező junior, csak 30% szenior, és csak ennél is kevesebb — mindössze 15% — az, aki 10 éves tapasztalattal rendelkező expert. Az emberek nem fogják észrevenni elsőre a gány kódokat, nem is tudják mindig, hogy gány, amit csinálnak. Ezért erre oda kell figyelni, és ez a mi feladatunk. A junioroknak meg kell tanítani, mi a gány és mi nem az.

Amikor egy egyszerű feladat sok időt vesz igénybe — pedig csak egy kis dolog, de valami miatt mégsem lehet egyszerűen megcsinálni —, akkor az iszonyatosan frusztráló, szuper frusztráló. Erodálja a motivációt, és erodálja a szervezetet is.

Uncle Bob elve, ami Boy Scout Rule néven ismert:

„Mindig hagyd a kódot egy kicsit jobb állapotban, mint ahogy találtad."

Az eredeti hasonlat a cserkészektől jön:

„Leave the campground cleaner than you found it."
(Hagyd tisztábban a tábort, mint ahogy találtad.) Ezt Martin ültette át szoftverfejlesztésre.

A programozásban ez nem azt jelenti, hogy nekiállsz átírni az egész modult, hanem például amikor amúgy is hozzányúlsz:

  • átnevezel egy félrevezető változót
  • kiszedsz egy duplikációt
  • egyszerűsítesz egy bonyolult if-et
  • törölsz dead code-ot
  • hozzáadsz egy hiányzó tesztet

Tehát kis lokális javítások, nem „refaktor projekt". Martin kifejezetten azt írja, hogy elég, ha egy kicsit tisztábban check-in-olod, mint ahogy kivetted.

Küzdjünk együtt a gány ellen!