Benedek Gergő
A technikai adósság, ahogy használhatnánk magyarul, egy kulcsfontosságú koncepció az IT minden területén, így a Machine Learning projektekben is. Minden fejlesztési folyamat tervezésekor bele lehet futni prioritási dilemmákba. Ebben a helyzetben segítséget jelenthet ez a cikk.
Előbb-vagy utóbb minden IT-szakembert utolér a Technical Debt. Ez néha tervezett és szándékos, máskor hívatlanul bukkan fel, akár teljesen véletlenszerűen. Nyilván arra törekszünk, hogy lehetőleg az első verzió történjen.
Bár gyakori jelenség, sokszor nehéz megfogalmazni a lényegét. Sokan sokféleképpen használják ezt a kifejezést.
Mi szeretjük a tiszta és egyszerű dolgokat. Egy munkadefinícióként elindulhatunk ezzel:
A Technical Debt produktív halasztgatás.
Alapvetően arról van szó, hogy a háttérbe tolsz valamit, ami most nem sürgős, cserébe ráfókuszálsz arra, aminek prioritása van. Az első dologhoz vissza kell térned idővel. És egészen addig, amíg a Technical Debt létezik, addig termelékenységi veszteséget generálhat.
De megéri! Ha a kisebb tüzeket ignoráljuk, akkor van időnk a legkomolyabb fenyegetésekkel foglalkozni, vagy előrehozni egy új és sürgős feature kiadását.
Technical Debt definíciók
A technical debt akkor keletkezik, amikor a szoftverfejlesztő felgyorsítja egy funkcionalitás létrehozásának folyamatát olyan módon, ami miatt később refaktorálásra lesz szükség. A tökéletes funkcionalitás helyett a sebességet priorizálja.
Az "adósság" ennek a priorizálásnak az eredménye. Ez az adósság megjelenhet bugok, legacy kód, hiányos dokumentáció formájában. Vagy jelenthet egy olyan feature-t, ami túl sok erőforrást igényel a jelenlegi formájában.
A technical debt extra munkát igényel, amit később el kell végezni, és ami általában egy olyan döntés eredménye, ami rövidtávú eredményeket céloz meg a hosszútávú célok kárára.
A Technical Debt típusai
A Technical Debt sokféle lehet. Az egyik legfontosabb jellemzője, hogy hogyan jött létre?
Lehet egy hosszútávú folyamat fontos része, létrejöhet egy technológiai frissítés miatt, vagy idővel gyakorlatilag magától is kialakulhat, valamilyen speciális beavatkozás elmaradása vagy a tágabb technológiai környezet megváltozása miatt.
Háromféle technikai adósságot különböztethetünk meg a kialakulás módja alapján:
- tudatos
- véletlenszerű / elavulás miatti
- a komplexitás növekedéséből adódó
Hogyan kezelendő a Technical Debt?
A technical debt megjelenését nem lehet elkerülni, de a kockázatokat korlátok közé lehet szorítani.
Let's go through the types mentioned above because they all require a different approach:
A tudatosan bevállalt Technical Debt esetében fontos, hogy nyomon kell követni a döntéseket. Amikor valaki azt mondja, hogy "erre majd később vissza kell térnünk", annak feltétlenül maradjon nyoma a projektdokumentációban. Aki ezzel kapcsolatban döntést hoz, annak vállalnia kell a felelősséget érte. Így lehet elkerülni azt, hogy a legváratlanabb pillanatban okozzon problémát ez a döntés.
Fontos az emberi tényező, mindig képben kell lenni azzal, hogy ki tudja értelmezni a programkódot! A csapat összetétele változik, de amikor valaki elmegy, azzal magával viszi a kóddal kapcsolatos specifikus tudásokat is. Ezért van az, hogy a Technical Debt már csak attól is megjelenhet, hogy személyi változások történnek! Ezért a kritikus információk átadására ki kell dolgozni egy megfelelő módszert.
Az elavuló design okozta problémák esélyét úgy lehet csökkenteni, hogy korlátok közé szorítjuk az üzleti irányváltásokat. Ez a fajta technical debt ugyanis akkor jelenik meg, amikor egy rendszert felépítünk bizonyos szempontok szerint, aztán hirtelen valami miatt meg kell változtatni a funkcionalitást. A régi rendszer sosem lesz képes optimálisan megfelelni az új elvárásoknak. Ha ez túl sokszor történik, a rendszer működése gazdaságtalanná válhat, és teljes újraépítésre lesz szükség.
A komplexitás növekedéséből fakadó technical debt hasonló az előzőhöz, de a változások itt aprók, inkrementálisak. Nyilván minden rendszerben szükség van időnként reorientációra, hiszen a technológia nem ül egy helyben. Az ebből fakadó problémákkal szemben úgy lehet védekezni, hogy előre tervezett időpontokban ellenőrizzük a rendszert, és kisebb, de folyamatos fejlesztőmunkákkal egyensúlyban tartjuk az egészet.
Vegyül figyelembe Lehman törvényeit:
1. Egy rendszert folyamatosan adaptálni kell, különben állandó mértékben csökken a megfelelősége
2. Ahogy a rendszer fejlődik, a kompexitása növekszik, ha külön munkafolyamatként nem csökkentjük vagy tartjuk szinten azt.
(Még hat pontja van ezeknek a törvényeknek, de az első kettő észben tartásával már megérjük azt, hogy a Technical Debt sokszor "csak úgy" megtörténik, anélkül, hogy aktívan beavatkoztunk volna a fejlesztésbe.)
A technical debt leggyakoribb okai
A technikai adósságot okozhatja:
- időbeli nyomás
- túlkomplikált kivitelezés
- gyenge megfelelés a szabványoknak
- a megfelelő képzettségek hiánya
- szuboptimális programkód
- késedelmes refaktorálás
- elégtelen mennyiségű tesztelés
A technical debt következményei
A technical debt többféle problémához vezethet:
- a fejlesztés sebessége csökken
- volatilissá váló teljesítmény
- gyengülő produktivitás
- túlterhelt tesztelés
A Technical Debt és a PoC (Proof of Concept)
A Technical Debt optimális esetben tudatos döntés eredménye. Ez abban a helyzetben a legegyértelműbb, amikor a Proof-of-Concept fázisba lépünk.
A PoC kulcsfontosságú rész a szoftverfejlesztésben, különösen innovációs partnerségi, illetve csapat-augmentációs együttműködésekben.
A PoC segítségével validáljuk a skálázhatóságot, a technikai potenciált és a végtermék kulcsfunkcióit egy kisebb léptékben.
Ez tipikusan az a helyzet, ahol már előre tudjuk, hogy a módszerek, amiket használunk, és a rendszerek, amiket építünk, nem véglegesek. Messze vannak még az optimalizációtól, csak a működőképességet akarjuk bizonyítani velük.
Hogyan lehet megakadályozni a Technical Debt megjelenését?
A Technical Debt egy természetes jelenség, de kockázatokat rejt. Nem lehet teljesen elkerülni, de lehet kezelni.
Az egyik tipikus probléma IT környezetben, hogy a fejlesztők túl sok időt kénytelenek tölteni régi programkódok javításával, amelyeket nem is ők hoztak létre. A belső képzések, a tiszta kommunikáció, az átgondolt átadás-átvétel folyamatok nagyon sok gondot tudnak megelőzni.
Ez talán kissé énközpontúan hangzik, de fontos, hogy a mérnököknek legyen lehetőségük visszajelezni a menedzsment és a felsővezetés irányába az üzleti oldalról érkező igények valódi kockázatairól és költségeiről.
A Lexunit sosem mond olyat, hogy valami lehetetlen. Bármilyen feladathoz alkalmazkodunk. Ezzel együtt az ügyfeleink abban is biztosak lehetnek, hogy mindig tökéletesen tisztában lesznek a kockázatokkal és utóhatásokkal, amikor elkötelezzük magunkat egy döntés mellett.
Tisztában vagyunk azzal, hogy a technikai tartozás sok esetben kifejezetten szükséges. Vannak fontos határidők, éles a verseny.
Amire igazán szüksége van egy IT-projekt megrendelőjének, az valaki, aki megmondja, ha a projekt átlép bizonyos határokat. Azt, amikor a döntéseknek akkora technical debt lenne a következménye, amennyi már veszélyezteti a célok elérését, az alapműködést. Az egész üzlet elsüllyedhet a technikai adósságok miatt - csakúgy, mint a pénzügyi adósság is válhat kezelhetetlenné.
A technical debt kezelése gyönyörű döntési helyzetek sorozata. Mély, rétegelt gondolkodásra van hozzá szükség. Mindig a jelenről, az "itt és most"-ról szól, de úgy, hogy közben a hosszútávú célokat és kihívásokat a figyelem középpontjában kell tartani.
Kövesd a Lexunit tartalomcsatornáit gyakorlati példákért arra, amikor útelágazáshoz ér a szoftverfejlesztés, érdekes sztoirkért a Machine Learning alkalmazásáról a startup világban, és más értékes megfigyelésekért az AI-fejlesztés területéről!