HTML

asdf

Másvalaki kódja

2020.11.07. 10:53 tvk

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

 

2 komment

A bejegyzés trackback címe:

https://kodzaj.blog.hu/api/trackback/id/tr4216276904

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

rmgm 2020.12.06. 17:28:04

Tök jó írás, de nekem ezek még mindig eléggé technikainak hatnak, és nem az embert magát kezelik. A Feathers könyvet én is ajánlom az olvasóknak, nagyon jó.

---

De ha már humán oldal, mindezek a problémák visszavezethetők az ego problémájára.

Nem az a gond, ha egy fejlesztő azt mondja, hogy "ez a kód szar", hanem az, amikor ezt saját egójának fényezésére, saját vélt vagy valós hibáinak elkendőzésére, mások lejáratására, ésatöbbi, tehát játszámázásra, hatalmi harcokra használja. A hétköznapjaink amúgy is tele vannak ilyenekkel, a koszos zokni el nem pakolása körül gerjedő vita is egy sok közül. Az IT-ban ráadásul sajnos jóval több az a fajta személyiség, akiben túlfejlett az ítélkező attitűd. Ez bizonyára szakmai sajátosság lehet. És általában nincs is szakmai segítség helyretenni ez egót. Jobb helyeken pszichológus/coach, rosszabb helyeken scrum master/line manager végzi ezt a nemes (gyötrelmes) feladatot. A többség meg magasról tesz rá, hogy hogyan működik a saját cégében az IT.

Jobb híján persze jók ezek a tüneti kezelések, de próbáld meg például kérdőre vonni egy kisebb cég technológiai igazgatóját, vagy egy nagyobb cégnél bármelyik architectet, aki éppenséggel az egyik legnagyobb fikázó a projekten. Jó eséllyel kapsz egy olyan választ tőle, hogy neki nincs arra ideje, hogy bizonygassa neked az álláspontját.
Nyilván a pórnépet lehet így leckéztetni, de ez közel sem teljes megoldás, ez ráadásul az egót inkább erősíti (mert megadja neki a játszma végi jutalmat), mintsem gyengítené, na meg senki sem fogja ettől jobban érezni magát a projekten. A játszmázó sem. Még ha rövid időre úgy is tűnik.

Ha az emberek nem ismerik meg magukat, a saját viselkedésük alapjait, nem tudják kezelni az egójukat, értelmetlen a szoftverfejlesztés humán oldaláról beszélni szerintem. Nem attól lesznek "humánusabbak" a fejlesztők, hogy bizonyítási kényszerrel terheljük őket. Attól, hogy nem veszi a fáradságot a bizonyításra, továbbra is azt fogja gondolni, hogy a kód szar, és - meglepetés - hasonlóan hanyag módon fog hozzányúlni. :D Legfeljebb nem hangoztatja. Persze nem tagadom, ismerek olyan céget, ahol ez elégséges már. Sajnos.

A legacy fejlesztő beültetése a csapatba jó ötlet, de az is csak akkor, ha amúgy nyitott a közösség. Ha ugyanúgy az egók dominálnak, akkor vagy veszekedés lesz, vagy nagy hallgatás és csak picit fikázzák a kódot. Viszont ha egymás elfogadása áll inkább a fókuszban, akkor legtöbbször a legacy fejlesztőt sem szükséges beültetni az új csapatba, mert vannak már annyira érettek a fejlesztők, hogy ítélkezés helyett az előrehaladással foglalkozzanak. Technikai segítségnek jó a legacy fejlesztő, de a humán oldalon nem hiszem, hogy tudna bármit is javítani.

Ezek az én tapasztalataim, gondoltam leírom. :)

Nehéz jó csapatjátékost találni. És nem feltétlenül az a jó csapatjátékos, aki beírja a CV-jébe. :)

---

Ha szabad, ajánlok én is egy könyvet, ami nem az IT-val, hanem az emberrel foglalkozik: Michael A. Singer - The Untethered Soul. Segít az ego felismerésében, Eric Berne - Emberi játszmák c. könyve meg az ego különféle megnyilvánulási formáit ecseteli.

tvk · http://kodzaj.blog.hu 2021.03.05. 09:22:39

Eléggé megkésve de köszi a kommentet, igazad van!

Az emberi oldallal kapcsolatban még két dolgot tudok hozzátenni:

- Már az interjúztatás közben ki lehet szűrni azokat akiknek túl nagy az egójuk, persze nyilván ez nem ilyen egyszerű. Ha ilyen egyszerű lenne akkor eleve én sem írtam volna a posztot.

- Létezik egy pozitív visszajelzés-adó tréning, ahol elmondják hogyan adjunk egymásnak visszajelzéseket sértés, degradálás és arrogancia nélkül. De aki eleve a többiek fölött érzi magát arra ez megintcsak nem hat.

Mindenesetre ezek olyan dolgok amik potenciálisan enyhíthetik a problémát.
Megnézem majd ezt a könyvet amit ajánlottál, jól hangzik!
süti beállítások módosítása