Mostanában a szoftverfejlesztés humán oldala kezdett el foglalkoztatni, leírom róla a meglátásaimat, tapasztalataimat. Nem kifejezettem másoknak akarom ezzel osztani az észt, inkább a saját gondolataimat akarom rendberakni. Szóval:

Manapság a kódot (még jó ideig) biztosan ember írja. A kód maga leginkább az aktuális céges szabványokon és szokásokon alapul, de elkerülhetetlenül tartalmaz valamennyit a programozó saját egyéni stílusából, ötleteiből. Ha kód review-re is sor kerül, akkor esetleg több programozó stílusa és ötletei is keverednek, jó esetben pozitív hatást okozva.

Egy kis kitérő:

Az elmúlt években több ismerősöm is vett használt lakást. Nagyon különböző, hogy ki mit kezd egy ilyen használtan vett kéróval. Van aki megejt egy tisztasági festést, kicserél pár elavult dolgot és kész, de van aki minden egyes falat arrébb pakol és a vizesblokkot is, mert minden pont úgy nem jó ahogy éppen van.

Nos, ugyanezt érzem a szoftverfejlesztésben is, amikor legacy kódon (jó kérdés mi a legacy kód...), vagy legalábbis másvalaki kódján kell dolgozni:

Bizonyos emberek elfogadják, hogy ez a kód így készült el, megvan mindennek az oka és tulajdonképpen az egy évek óta működő és pénzt termelő rendszer. Próbálják megérteni, apró kicsi változtatássokkal jobbá tenni. Hogy konkrétumokat is írjak: egyértelmű elírásokat, standardtól való eltéréseket javítani, unit teszteket írni, ha nem tesztelhető akkor megpróbálni némileg tesztelhetővé tenni és ezután bevezetni új változtatásokat.

Mások nem próbálják meg elfogadni és megérteni a létező kódot, a saját stílusukban gondolkodnak, azt próbálják ráültetni. Ez persze nehéz, vagy nem működik. Az új változtatásokat hozzáfércelik a meglévő kódhoz és ha bug jelentkezik a régebbi kódot hibáztatják. Tipikus kijelentések ebben a szituban: ez az egész össze fog omlani, újra kéne írni az egészet, ezt lehetetlen továbbfejleszteni. Természetesen az újraírásnak is megvan a létjogosultsága bizonyos esetekben, de nem anélkül hogy minimális szinten megpróbáljuk megérteni az eredetit.

A szituációt az is nehezíti, ha a kód eredeti szerzői már nem dolgoznak az adott projekten. Ilyenkor nincs aki érveljen a kódban szereplő stílus és ötletek mellett.
Ráadásul, tapasztalataim szerint a legtöbb fejlesztő számára, ha át kell venni másvalaki projektjét, az morális csapás, bármilyen minőségű is az átvett projekt. Még sosem találkoztam olyan esettel, amikor egy átvett projekt friss gazdái jóízűen csettintettek, hogy "ejha de szép kód, de szép projekt, de tetszik". Inkább azt hallottam, hogy "úristen milyen érthetetlen katyvasz ez" még ha az előző tulajdonosok az egekbe is magasztalták a saját stílusukat.

Valójában ez nem meglepő. Már (Java és JS világban legalábbis) rengeteg féle framework és nyelvi elem létezik, frameworkökön belül is sok megoldás és azok konstellációja, és ezek nem mindig könnyen érthetőek első ránézésre. Nem esik le egyből a tantusz, esetleg kell pár hét aktív tapasztalat mire rááll az ember agya, hogy erőlködős nélkül tudja értelmezi az idiómákat.

Tudnék még ezen pörögni, de inkább leírok pár tanácsot ami segíthet a hasonló problémák leküzdésében:

• Lehetőleg minimalizálni kell a projekt átadás-átvételek számát, vagy legalábbis okosan csinálni, átmenetekkel, beszoktatási időszakot beiktatva. A régi programozók közül valakit ideiglenesen betenni az új csapatba. Nem is tudom, talán ettől függetlenül kötelezővé is tenném, hogy fél évente legyen valami embermozgás csapatok között bár ez így nagyon rosszul hangzik.
• A nagyszájú developereket szerintem finoman helyre kell tenni előbb-utóbb. Ha panaszkodik hogy katyvasz a kód, konkrétan bele lehet kérdezni hogy érti-e a projekt domain vagy technikai szintű koncepcióit. Ha nem érti akkor lehet mondani hogy akkor még tanulgassa, vagy gondolkodjon hogy mit akar. Ha vannak saját nagyobb volumenű ötletei akkor megkérni, hogy dolgozza ki őket részletesen, bocsássa vitára, becsüljük meg együtt mennyi idő megvalósítani aztán kérdezzük meg az illetékes PM-eket hogy mehet-e. Legtöbb esetben ezek az ötletek elhalnak már az első lépésnél amikor ki kéne dolgozni őket rendesen. De ha nem, annál jobb mert akkor talán tényleg megvalósíthatóak. Kisebb volumenű kód módosítási ötleteket egy exploratory refaktor során lehet validálni, esetleg pair programozás keretében. Itt is, az egyszerűen induló refaktor eldurvulhat és akkor egy "na jó, inkább hagyjuk" sóhaj keretében mindenki mehet a dolgára, de ha sikerül akkor örülünk.
• Semmelyik projekt sem élhet a végtelenségig. Előbb-utóbb valóban újra kell írni, meg kell szüntetni vagy ki kell találni helyette valamit. Ez nem szokás, de én már a projekt kezdetekor elgondolkodnék exit stratégiákon: mi lesz ha majd elavul az éppen alkalmazott technológia vagy fundamentálisan megváltoznak a körülmények? A mikroservice architektúrák egyébként viszonylag jól kezelik ezeket a forgatókönyveket, legalábbis részben, de nem minden business helyzetben triviális megvalósítani őket.
• Végezetül, ezt a könyvet melegen ajánlom a témában. A végtelenül unalmas cím nagyon hasznos és izgalmas kontentet takar:
  Michael Feathers - Working Effectively with Legacy code