Hogyan gondoskodjunk a kódról?

Ki felelős egy adott kódért? Egy fejlesztő, vagy az egész csapat? Gyakori kérdés, mégsem egyszerű a válasz, főleg, ha figyelmen kívül hagyjuk, hogy az érintett fejlesztők belső motivációja nélkül mindegy, hogy melyik utat választjuk.

Az egyoldalú döntések kockázata

Abban megegyezhetünk, hogy vezetői szemmel már egy közepes méretű cég esetén is kockázatos, hogy a szoftver egy-egy részét egyedül "birtokolják" egyes fejlesztők. Mindenki lehet beteg, ahogy mindenki megy nyaralni is időnként, és ilyenkor előre nem látható késések léphetnek fel a feladatok elvégzésében. Sőt, azzal sem mondunk újat, hogy bárki bármikor felmondhat, amivel nem csak a kedvenc bögréjét, hanem a nála lévő tudás nagy részét is viszi a cégből.

A másik oldalon persze ott van a tény, hogy a fejlesztők nem (és valószínűleg más szakemberek sem) szeretik, ha helyettesíthető munkaerőként tekintenek rájuk. Mi több, valljuk be, hogy legtöbbünknél a mindennapi motivációba is besegít, hogy el tudunk mélyülni egy adott témában, gyerekünként kezeljük, óvjuk azt a részét a kódnak, és a lehető legtöbbet próbáljuk kihozni belőle, ami büszkeséggel tölt el bennünket. Ez a motiváció az, ami a legtöbb esetben biztosítja azt is, hogy az adott kód folyamatosan karban legyen tartva, ami könnyen felismerhető ellentmondáshoz vezet.

Persze a kód "birtoklása" önmagában amúgy sem lenne elég, gondoljunk csak arra, amikor valaki mástól örököl meg egy - jó eséllyel - mostoha sorsú alkalmazást, majd viszonylag hamar eljut arra a pontra, ahol legszívesebben csak felgyújtaná az egész repót, vagy legalábbis a 90%-át újraírná. Bár kockázatos lehet, de az utóbbi megoldás abból a szempontból sikeres lehet, hogy így jobban magáénak érezheti az új kolléga a problémás részeket, és ez által motiváltabb lesz a későbbi "gondoskodásra" is.

Ahogy látjuk, az egyszemélyes felelősség ellen és mellett is számos érv szól, ugyanakkor a legfontosabbról ne feledkezzünk meg: az egyéni ownership valószínűleg rengeteg egyoldalú döntéssel is jár, ami egy 5 fősnél nagyobb cégben ritkán szerencsés hosszú távon.

Hagyjuk, hogy a csapat tegye a dolgát

Ha egynél több fejlesztő dolgozik egy projekten, az az esetek többségében azért jelentős előnyökkel jár. Már a tervezés során több hibára derülhet fény, hatékonyabbak az ötletelések, és mivel ezek kimenete jó esetben egy konszenzus eredménye, ezért minden fél valamennyire magáénak tudja érezni a feladatokat, ezzel együtt pedig a felelősséget is. 

A képlet persze ennyire nem egyszerű, nem hagyhatjuk ugyanis figyelmen kívül, hogy megvan-e a kémia a csapat tagjai között, amit nem lehet egy varázsütéssel elérni a semmiből. Ilyen szempontból nem biztos, hogy érdemes heterogén csapatokkal kísérleteznünk, ahol merőben eltérő személyiségű embereket akarunk csoportosan munkára bírni.

Mi a helyzet a komplex projektekkel?

Röviden az, hogy a fentiek nem igazán működőképesek :( Az igazán bonyolult üzleti logikát és komplex szolgáltatásokat maguk mögött tudó alkalmazások mindig ki fogják termelni a saját szakértőiket. Ahhoz ugyanis, hogy az ilyen projekteken is elterjedhessen a szélesebb körű felelősségvállalás, a fejlesztőknek annyi, és olyan tudást kellene magukra szedniük, ami nem feltétlenül érné meg a végén az elégetett erőforrásokat tekintve.

Ilyen esetben az működhet jól, ha van egy - preferáltan több fős - core csapat, akik validálják a többi fejlesztő hozzárakott munkáját. Úgy kell elképzelni a modellt, mint a nyílt forrású szoftverek működését, az egyes merge requesteket egy jól körülhatárolható csoport vizsgálja adott esetben, ezzel biztosítva, hogy ne kerülhessen be olyan dolog a kódba, ami nem oda való.

A közös felelősség útvesztői

Persze, ha egy kódnak több gazdája van, attól még nem lesz rögtön minden tökéletes, sőt. Nem nehéz pl. elképzelni, hogy az egyik kolléga a szabadságáról visszatérve megjegyzést tesz a távolléte alatt történt változtatások minőségére, és az ilyen jellegű súrlódások még csak a jéghegy csúcsát jelentik. A nagyobb problémák inkább akkor kezdődnek, amikor valaki egy ilyen csapatban alulmotiválttá válik. Ennek számos oka lehet, akár magánéleti gondok, akár egy elmaradt fizetésemelés, vagy a főnökkel szembeni konfliktus is. Ha valaki ilyenkor kevésbé törődik már a kóddal (és úgy általában a munkája minőségével), akkor ez sajnos nagyon hamar elterjedhet az egész csapatban. 

Így születnek code review-k felületes véleményezéssel, új funkciók tesztek és dokumentáció nélkül, és így veszti el a csapatból szépen lassan mindenki a hitét a közös termékben. Sajnos a megosztott felelősség ebben az esetben a problémák igazi gyökerét - és ezzel együtt a személyes felelősséget - elfedi, bár ez igaz a sikerek esetén is.

Aminek mindenki a gazdája, annak nincs gazdája

Bizony, ez így van. Ha bármilyen komponensről azt mondjuk, hogy márpedig azért mindenki felelős a fejlesztők közül, akkor nagyon gyorsan válik majd gazdátlanná a terület. Ezzel együtt megjelennek a gyors és egyszerű, de hosszú távon fenntarthatatlan javítások ezekben a kódbázisokban, hiszen senki se fog értük valós felelősséget érezni. A kör pedig ezzel be is zárul, a cégnél gyorsan elterjed, hogy ez AZ a kód, és inkább bottal se piszkálja senki, ami szintén nem szokott jó hatással lenni a minőségre.

Gondoskodás = siker

Összességében kijelenthető, hogy felvehetjük a világ legjobb fejlesztőit, és összerakhatjuk velük a legjobb agilis csapatokat, akik ismerik az összes buzzword-öt és új keretrendszert, akkor sem lesznek sikeresek hosszú távon, ha nem éreznek felelősséget az általuk írt kód, és a munkájuk minősége iránt. Hogy ezt elősegítsük, az egyik legjobb módszer, ha egyértelmű határokat és irányvonalakat húzunk a code ownership kapcsán, a többit pedig a fejlesztők belső motivációjára bízzuk.

Forrás: Bruno Filippone