Technikai adósság a mobilfejlesztésben — lényeg, típusok és kezelési elvek

Mi az a technikai adósság (Technical Debt)

Technikai adósság (Technical Debt) — egy metafora, amelyet először Ward Cunningham javasolt 1992-ben az OOPSLA-n. Összehasonlította a programozást a beruházással: a hanyag kód egy felvett kölcsön. Kamatját többletidő formájában fizetik a karbantartásra, hibajavításra és új követelményekhez való alkalmazkodásra. Fontos megérteni, hogy az adósság nem mindig rossz; a stratégiai adósság indokolt lehet.

Pénzügyi analógia szinte szó szerint működik. Ha egy csapat kölcsönt vesz fel (nem ideális kódot ad ki, hogy betartsa a határidőt), kamatot kell fizetnie. Kamat — a fejlesztés lelassulása, hibák a kód megváltoztatásakor, az új fejlesztők betanításának nehézsége. Ha a kamat magasabb lesz, mint a refaktorálás költsége — itt az ideje az adósság visszafizetésének. A fő probléma: a banki kölcsönnel ellentétben a fejlesztők nem mindig tudatában annak, hogy adósságot vettek fel.

Fontos pontosítás: technikai adósság ≠ rossz kód. Rossz kód — az alkalmatlanság következménye. Technikai adósság — tudatos kompromisszum. A csapat megérti, hogy nem ideális munkát végez, rögzíti ezt a műszaki dokumentációban, és tervezi a visszatérést a fejlesztéshez. Az adósság és a rossz kód közötti különbség a döntés tudatosságában rejlik. Ezért az adósságkezelés első lépése — elismerni annak létezését.

A technikai adósság típusai

A technikai adósság osztályozása segít megérteni annak természetét és kiválasztani a megfelelő visszafizetési stratégiát. Martin Fowler egy negyedmodellt javasolt két téngellyel: szándékos/nem szándékos és meggondolatlan/előrelátó. Minden kombináció más megközelítést igényel. Nézzük meg a fő adósságtípusokat, amelyekkel egy mobilfejlesztő csapat szembesül.

Szándékos és nem szándékos adósság

Szándékos adósság — a csapat tudatosan dönt úgy, hogy nem optimális kódot ad ki a határidő betartása érdekében. Példa: egy MVP elindítása egyetlen monolit ViewModel-lel, tudva, hogy a hipotézis érvényesítése után a ViewModel tartományok szerint lesz felosztva. Az ilyen adósságot rögzítik a backlogban, és tervezett visszafizetési határideje van. Terv nélkül a szándékos adósság krónikussá válik.

Nem szándékos adósság — kód, amelynek minősége alacsonyabb a vártnál a tudáshiány, a kódellenőrzés hiánya vagy a rossz folyamatok miatt. Példa: a fejlesztő nem ismerte a Room DB-vel való munka legjobb gyakorlatait, és lekérdezéseket írt a UI szálba, ANR-t okozva. Az ilyen adósság a leg alattomosabb — a csapat nem veszi észre, amíg kritikus teljesítményproblémákkal nem szembesül.

Architektúrális és kódadósság

Architektúrális adósság — a minták vagy a projektstruktúra helytelen megválasztása. Példa: alkalmazás a hálózat feletti absztrakciós réteg nélkül, ahol a Retrofitot közvetlenül a ViewModel-ből használják. A Retrofit Ktorra cserélése az összes ViewModel módosítását igényli. Az architektúrális adósság javítása a legdrágább, ezért az architektúra szintjén hozott döntések maximális óvatossággal történnek.

Kódadósság — helyi nem optimális részek egyetlen osztályon vagy metóduson belül. Példa: hosszú metódus 200 sorral, ahol a UI, üzleti logika és adatkezelés összekeveredik. Extract Method-mal 15 perc alatt javítható. A kódadósság kevésbé kritikus, de felhalmozódása a projekt méretében nem kevésbé lassítja a fejlesztést, mint az architektúrális adósság.

Tesztelési és dokumentációs adósság

Tesztelési adósság — unit tesztek, UI tesztek vagy integrációs tesztek hiánya. Minden kézi regressziós futtatás kamat erre az adósságra. Ha a projektben nincsenek automatizált tesztek, minden változtatás órákig tartó kézi tesztelést igényel. A Google Testing Blog szerint a >70%-os tesztlefedettséggel rendelkező projektek kétszer ritkábban bocsátanak ki hibákat élesbe.

Dokumentációs adósság — az architektúrális dokumentáció, az összetett kódrészek kommentjeinek, a betanításhoz szükséges readme hiánya vagy elavulása. Az új fejlesztő heteket veszít a betanulással dokumentáció nélkül. Megoldás: Architecture Decision Records (ADR) karbantartása és a dokumentáció a Definition of Done részévé tétele minden feladathoz.

Miért veszélyes a technikai adósság

Kamatos kamat hatása — a technikai adósság fő veszélye. A nem optimális kód minden új rétege nem lineárisan, hanem exponenciálisan növeli a rendszer összetettségét. Egyszerű példa: ha az A modul függ a B modultól, és mindkettő tartalmaz adósságot, akkor az A-ban végrehajtott változtatás megköveteli a B-ben lévő adósság megértését. 10 iteráció után a fejlesztő az idő 80%-t a függőségek kibogozására és csak 20%-t — új funkcionalitásra fordítja.

A time-to-market lelassulása — az adósság közvetlen következménye. A csapat egyre több időt fordít a karbantartásra és egyre kevesebbet az új funkciókra. A Stripe (2023) kutatása kimutatta, hogy a fejlesztők átlagosan heti 17 órát töltenek a technikai adóssággal való munkával, ahelyett, hogy értéket teremtenének az üzlet számára. A mobilfejlesztésben ezt súlyosbítja a két platform támogatásának szükségessége — mindegyik saját platformfrissítésekkel.

Csapat kiégése — nem nyilvánvaló, de pusztító következmény. A munka olyan kódban, ahol minden változtatás három mást tönkretesz, krónikus stresszt okoz. A fejlesztők megszűnnek büszkék lenni a termékre, a motiváció csökken, a fluktuáció nő. A Stack Overflow Survey 2024 szerint a legacy kóddal való munka a második leggyakoribb elégedetlenségi ok az alacsony fizetés után.

Hogyan kezeljük a technikai adósságot

Fowler negyede — gyakorlati eszköz az adósság rangsorolásához. Két téngely: szándékos/nem szándékos és meggondolatlan/előrelátó. Meggondolatlan szándékos adósság: “nincs időnk tesztekre, kiadjuk nélkülük”. Előrelátó szándékos adósság: “tudjuk, hogy kellenek tesztek, de most fontosabb a funkció elindítása – létrehozunk egy feladatot a tesztekhez a következő sprintben”. Az első azonnali beavatkozást igényel, a második — ellenőrzést.

Boy Scout Rule stratégia — “hagyd a táborhelyet tisztábban, mint ahogy találtad”. Egyszerű szabály: egy metódus módosításakor fordíts 10%-kal több időt, hogy egy kicsit jobbá tedd — nevezd át a változót, ossz fel egy 50 soros blokkot ketté. Csapat szinten ez a megközelítés az adósság fokozatos csökkenését eredményezi anélkül, hogy külön sprintet kellene szánni a refaktorálásra. A fejlesztésnek mikroszkopikusnak, de rendszeresnek kell lennie.

Idő elkülönítése az adósság kezelésére — a csapat érettségének jele. Javasolt a sprint 15–20%-t technikai fejlesztésekre fenntartani. Ez nem jelenti azt, hogy a csapat heti 1 napot nem csinál mást, csak refaktorál. A technikai feladatok egyenletesen oszlanak el: metrikák javítása, forró pontok refaktorálása, függőségek frissítése. Elkülönített idő nélkül az adósság folyamatosan nő.

// Boy Scout Rule stratégia működés közben
// Volt: olvashatatlan módszer varázsszámokkal
fun calc(a: Int): Int = a * 60 * 1000

// Lett: olvasható módszer konstansokkal
private const val SECONDS_IN_MINUTE = 60
private const val MILLIS_IN_SECOND = 1000

fun minutesToMillis(minutes: Int): Int =
    minutes * SECONDS_IN_MINUTE * MILLIS_IN_SECOND

Automatizálás az adósság észlelésére — a kezelés harmadik pillére. Állíts be értesítéseket a hosszú metódusok (>30 sor), osztályok (>500 sor), túlezásos egymásba ágyazás (>5 szint) észlelésére. Használd a Danger vagy hasonló eszközöket automatikus megjegyzésekhez pull requesteken: ha egy metódus túllépi a komplexitás küszöbértékét, a bot azt írja: “Ennek a metódusnak a ciklomatikus komplexitása 12 — kérjük, fontolja meg a felosztást”. Az automatizálás csökkenti a kódellenőrzés terhét.

Eszközök az adósság elemzéséhez

SonarQube — a legnépszerűbb platform a technikai adósság elemzésére. Kiszámítja a ‘javításhoz szükséges napok számát’ — egy menedzserek számára érthető mutatót. A SonarQube támogatja a Kotlin, Swift, Java, Python és más nyelveket. Integrálódik a CI/CD pipeline-ba és nem engedi át a pull requestet, ha az adósság meghaladja a küszöböt. A mobil csapatok számára ez a de facto szabvány.

Android csapatok számára a Detekt (Kotlin statikus elemzése) és az Android Lint is használatos. A Detekt kiszámítja a kódmetrikákat és megtalálja a Code Smell mintákat. A SonarQube Android Gradle bővítmény egyetlen jelentésbe egyesíti az eredményeket. iOS csapatok számára — SwiftLint statikus elemzéshez és Periphery a nem használt kód megtalálásához. Az Xcode Organizer teljesítménymetrikákat mutat, amelyek gyakran korrelálnak az architektúrális adóssággal.

CodeClimate és CodeFactor — felhő alapú megoldások, amelyek GitHub/GitLab tárolókat elemeznek és mutatják az adósság dinamikáját. Értékelnek minden commitot, lehetővé téve annak nyomon követését, hogy mikor kezdett nőni az adósság. A Maintainability grafikon — érthető eszköz a vezetőséggel való kommunikációhoz: „látja a csúcspontot márciusban? Akkor kényszerítettük a kiadást és 3 napnyi javítási adósságot halmoztunk fel”.