Bármely vállalkozás életében eljöhet a pont, hogy egy üzletikleg kritikus szoftver, ami az üzleti célok elérését hivatott kiszolgálni, egyszer csak akadállyá válik. Az idő múltával ahelyett, hogy segítené a mindennapi munkát, már alkalmazkodni kell a korlátaihoz és adottságaihoz.
Ennek oka általában az, hogy a szervezet fejlődik vagy az üzleti környezet megváltozik, ami miatt
más jellegű folyamatokra és működésre van szükség, de a megvásárolt vagy megépített termék ehhez már nem illeszkedik.
Gyakran előfordul az is, hogy a rendszerhez már csak egy-két ember ért, mégis folyamatosan van vele teendő, aminek a költsége komoly teherré válhat.
Szoftverfejlesztőként mi magunk is szembesülünk a problémával, valahányszor egy olyan rendszerhez kell nyúlnunk, amit régóta nem tartottunk karban. Ezeken legtöbbször senkinek sincs igazán kedve, energiája vagy ideje dolgozni, esetleg éppen a tudása hiányzik hozzá.
A szoftver legnagyobb értéke a rugalmassága
A neves programozó, a Clean Code-könyvek szerzője, Uncle Bob szerint minden szoftvernek két értéke van:
- Az egyik a viselkedése: azok a funkciók, amelyeket a felhasználók látnak és használnak, melyeken keresztül a szoftver segít elvégezni a feladataikat.
- A másik – kevésbé látványos – érték a szerkezete, ami arról tanúskodik, hogy mennyire könnyen érthető, bővíthető és módosítható a forráskód. Ez teszi a szoftvert igazán rugalmassá és garantálja hosszú távon, hogy a rendszer követni tudja a változó üzleti igényeket ahelyett, hogy lassítaná azokat.
Uncle Bob szerint egy rendszer mindig az utóbbi hiányában válik akadállyá.
Ha egy rendszer nem fejleszthető tovább, az szoftvermérnökként kudarc:
a két érték közül csak az egyiket építettük be rendszerünkbe és munkánknak csak a könnyebb felét végeztük el. Állítása szerint egy hibásan működő, de jó szerkezettel rendelkező szoftvert könnyebb megjavítani, mint egy rossz szerkezetű, de helyesen működő rendszert továbbfejleszteni.
Legtöbbször ez a jelenség áll amögött, mikor egy tapasztalt fejlesztő nem boldogul egy „legacy”-nak (örököltnek, elavultnak) nevezett, ún. „spagetti”-kódbázissal. (Lásd még korábbi írásunkat a témában. – A szerk.)
Mivel régóta nem volt ápolva a rendszer architektúrája/szerkezete, ún.
technikai adósság (technical debt) halmozódott fel, amit előbb-utóbb meg kell fizetni.
A helyzetet tovább nehezíti, ha a szoftver technológiai alapjai és függőségei elavultak, vagy hiányoznak az automatizált tesztek, a dokumentáció vagy a naprakész kompetencia a csapatban. A fejlesztőcsapat ilyenkor látszólag lassan (vagy egyáltalán nem) halad a rábízott feladatokkal, illetve rengeteg hibával küzd.
Mitévő lehet egy üzleti szereplő ebben a helyzetben?
A rendrakás napi szokás, nem egyszeri nagytakarítás
Ahogy egy elhanyagolt konyhában is előbb-utóbb lehetetlenné válik a főzés, egy kódbázis is erre a sorsra jut, ha nem foglalkozunk vele rendszeresen. Nem elég évente egyszer nagytakarítást végezni: napi szinten kell megtalálnunk a rendrakás és takarítás helyét, és olyan állapotban kell hagynunk a kódbázist magunk után, hogy azon kollégáink is könnyen, magabiztosan tudjanak tovább dolgozni.
Ezt a gyakorlatot kialakítani sokkal inkább kulturális kérdés, mintsem technikai.
Azok a csapatok, ahol ez a szokás nem része a mindennapoknak, előbb-utóbb a fent leírt helyzettel szembesülnek. Ahelyett, hogy szőnyeg alá söpörnénk a témát, sokkal értékesebb tudatosan felkészülni rá és időben mérlegelni, hogyan előzhetjük meg.
Megoldások
A piacon két stratégia szokott felmerülni a legacy-rendszerek okozta problémák megelőzésére:
- írjuk újra az egészet, vagy
- ne nyúljunk hozzá egyáltalán, hiszen működik.
Bizonyos helyzetben ezek járható utak és indokolt döntések lehetnek, de a kettő között számtalan más lehetőségünk is van.
A fokozatos, kis lépésekben végzett modernizáció épp ennyire valós opció. Sőt, tapasztalataink szerint sok esetben
ez a leginkább költséghatékony, mert egyszerre teremt üzleti értéket és tesz rendet a rendszerben.
Az AI támpontokat adhat, de nem old meg mindent
Tapasztalatunk szerint a mesterséges intelligencia által a fokozatos modernizáció sokkal elérhetőbb lett.
Az AI-eszközök ma már valóban jól segítenek abban, hogy egy meglévő rendszer működését megismerjük, dokumentáljuk, akár utólag automatizált tesztekkel fedjük le vagy éppen napi automatizmusok révén kis lépésekben tegyük élhetőbbé.
Az AI segítő kezet nyújt, de ez önmagában nem elég. A mérnököknek kulturálisan és kompetencia szempontjából is fel kell készülniük a kihívásokra, mert egy legacy-rendszerrel dolgozni egészen más, mint egy zöldmezős projekten. Itt
a legnagyobb érték a tapasztalat: amikor egy csapat már sok ilyen helyzetet látott, és ismeri a jellemző kockázatokat és stratégiákat.
Ezek olyan képességek, amiket nem lehet egyik napról a másikra elsajátítani. Tudatosan kell fejleszteni őket csapatszinten éppúgy, mint egyénileg.
Ebben már sokkal kevésbé segítség bármiféle AI-eszköz, hiszen azt a gondolkodásmódot és intuíciót kell kialakítani, ami erős szakmai alapokra építve működik csak jól.
Saját életünkben azt látjuk működő mintának, ha teret adunk a technikai stábnak, és bátorítjuk a fejlesztőket arra, hogy napi szinten tegyék jobbá azt a kódbázist, amiben dolgoznak.
Az üzleti célok elérése, új funkciók fejlesztése mellett elengedhetetlen erre is erőforrást delegálni a későbbi problémák elkerülése érdekében. Ez rövid távon pénzkidobásnak tűnhet, hiszen funkcionálisan nem lesz több a rendszerünk, viszont
ez egy olyan befektetés, ami hosszú távon hozzájárul üzleti céljaink eléréséhez és a kivitelező csapat szakmai jóllétéhez.
Folytassuk élőben!
Előadó: Ivanics Péter, CTO @Webstar
Van, hogy egy új nézőpont visz közelebb a megoldáshoz
Mire számíthatsz?
Add meg néhány adatodat, és máris küldjük szakértői tartalmunkat!
SIKERES FELIRATKOZÁS ÉS LETÖLTÉS!
Hamarosan érkezik a megadott e-mail-címre szakértői dokumentumunk.
