Mobil inkişafda texniki borc — mahiyyəti, növləri və idarəetmə prinsipləri

Texniki Borc (Technical Debt) nədir

Texniki borc (Technical Debt) — ilk dəfə 1992-ci ildə OOPSLA konfransında Uord Kanningem tərəfindən təklif edilən metaforadır. O proqramlaşdırmanı investisiya ilə müqayisə etdi: səliqəsiz kod — götürülmüş kreditdir. Onun faizləri əlavə dəstək vaxtı, səhvlərin düzəldilməsi və yeni tələblərə uyğunlaşma şəklində ödənilir. Anlamaq vacibdir ki, borc həmişə pis deyil; strateji borc əsaslandırıla bilər.

Maliyyə analogiyası demək olar ki, hərfi mənada işləyir. Əgər komanda kredit götürərsə (müddətə çatmaq üçün qeyri-ideal kod buraxır), o faiz ödəməlidir. Faizlər — inkişafın yavaşlaması, kod dəyişikliyində səhvlər, yeni tərtibatçıların onboardinqinin çətinliyidir. Əgər faizlər refaktorinqin dəyərindən yüksək olarsa — borcu ödəmək vaxtıdır. Əsas problem: bank kreditindən fərqli olaraq, tərtibatçılar həmişə borc götürdüklərini dərk etmirlər.

Vacib qeyd: texniki borc ≠ pis kod. Pis kod — bacarıqsızlığın nəticəsidir. Texniki borc — şüurlu kompromisdir. Komanda başa düşür ki, qeyri-ideal iş görür, bunu texniki sənədləşmədə qeyd edir və yaxşılaşdırmağa qayıtmağı planlaşdırır. Borc və pis kod arasındakı fərq — qərarın şüurlu olmasındadır. Buna görə borcu idarə etməyin ilk addımı onun mövcudluğunu qəbul etməkdir.

Texniki borcun növləri

Texniki borcun təsnifatı onun təbiətini anlamağa və düzgün ödəmə strategiyasını seçməyə kömək edir. Martin Fowler iki oxlu kvadrant modelini təklif etdi: qəsdən/qəsdən olmayan və ehtiyatsız/ehtiyatlı. Hər kombinasiya fərqli yanaşma tələb edir. Mobil inkişaf komandasının qarşılaşdığı əsas borc növlərini nəzərdən keçirək.

Qəsdən və qəsdən olmayan borc

Qəsdən borc — komanda şüurlu şəkildə deadlaynə çatmaq üçün qeyri-optimal kod buraxmağa qərar verir. Nümunə: fərziyyənin təsdiqlənməsindən sonra ViewModel-in domenlər üzrə bölünəcəyini bilərək MVP-ni tək monolit ViewModel ilə işə salmaq. Belə borc backlogda qeyd olunur və planlaşdırılmış ödəmə müddəti var. Plansız qəsdən borc xroniki hala çevrilir.

Qəsdən olmayan borc — bilik çatışmazlığı, kod nəzərdən keçirmənin olmaması və ya zəif proseslər səbəbindən keyfiyyəti gözləniləndən aşağı olan kod. Nümunə: tərtibatçı Room DB ilə işin best practices-lərini bilmirdi və UI thread-də sorğular yazaraq ANR-yə səbəb olurdu. Belə borc ən hiyləgərdir — komanda kritik performans problemləri ilə qarşılaşana qədər onu dərk etmir.

Arxitektura və kod borcu

Arxitektura borcu — layihənin naxışlarının və ya strukturunun səhv seçimi. Nümunə: şəbəkə üzərində abstraksiya qatı olmayan tətbiq, burada Retrofit birbaşa ViewModel-dən istifadə olunur. Retrofit-in Ktor ilə əvəz edilməsi bütün ViewModel-lərin dəyişdirilməsini tələb edəcək. Arxitektura borcunun düzəldilməsi ən bahalıdır, buna görə arxitektura səviyyəsində qərarlar maksimum ehtiyatla qəbul edilir.

Kod borcu — ayrıca sinif və ya metod daxilində lokal qeyri-optimallıqlar. Nümunə: UI, biznes məntiqi və məlumatlarla işin qarışdığı 200 sətirlik uzun metod. Extract Method ilə 15 dəqiqəyə düzəldilir. Kod borcu daha az kritikdir, lakin onun layihə miqyasında yığılması inkişafı arxitektura borcundan az yavaşlatmır.

Test və sənədləşmə borcu

Test borcu — Unit-testlərin, UI-testlərin və ya inteqrasiya testlərinin olmaması. Hər əl ilə reqressiya işə salması bu borcun faizidir. Layihədə avtotestlər yoxdursa, hər dəyişiklik saatlarla əl ilə test tələb edir. Google Testing Blog-a görə, test əhatəsi >70% olan layihələr 2 dəfə az səhvi produksiyaya buraxır.

Sənədləşmə borcu — arxitektura sənədləşməsinin, mürəkkəb kod hissələrinə şərhlərin, onboardinq üçün readme-nin olmaması və ya köhnəlməsi. Yeni tərtibatçı sənədləşmə olmadan həftələrlə vaxt itirir. Həll yolu: Architecture Decision Records (ADR) saxlamaq və sənədləşməni hər tapşırıq üçün Definition of Done-un bir hissəsi etmək.

Niyə texniki borc təhlükəlidir

Mürəkkəb faiz effekti — texniki borcun əsas təhlükəsi. Qeyri-optimal kodun hər yeni qatı sistemin mürəkkəbliyini xətti deyil, eksponensial olaraq artırır. Sadə nümunə: əgər modul A modul B-dən asılıdırsa və hər ikisi borc ehtiva edirsə, A-da dəyişiklik B-də borcun başa düşülməsini tələb edir. 10 iterasiyadan sonra tərtibatçı vaxtının 80%-ni asılılıqları açmağa və yalnız 20%-ni yeni funksionallığa sərf edir.

Time-to-market-in yavaşlaması — borcun birbaşa nəticəsidir. Komanda getdikcə daha çox vaxtı dəstəyə və daha azını yeni funksiyalara sərf edir. Stripe (2023) tədqiqatı göstərdi ki, tərtibatçılar həftədə orta hesabla 17 saatı texniki borcla işləməyə sərf edir, biznes üçün dəyər yaratmağa yox. Mobil inkişafda bu, hər biri öz platforma yeniləmələri ilə iki platformanı dəstəkləmək zərurəti ilə daha da pisləşir.

Komandanın tükənməsi — gözə çarpmayan, lakin dağıdıcı nəticə. Hər dəyişikliyin üç digərini pozduğu kodda iş xroniki stressə səbəb olur. Tərtibatçılar məhsulla fəxr etməyi dayandırır, motivasiya düşür, kadr axını artır. Stack Overflow Survey 2024-ə görə, legacy-kodla iş aşağı maaşdan sonra işdən narazılığın ikinci ən çox yayılmış səbəbidir.

Texniki borcu necə idarə etməli

Fowler kvadrantı — borcun prioritetləşdirilməsi üçün praktik alət. İki ox: qəsdən/qəsdən olmayan və ehtiyatsız/ehtiyatlı. Ehtiyatsız qəsdən borc: "testlərə vaxtımız yoxdur, onsuz buraxırıq". Ehtiyatlı qəsdən: "testlərin lazım olduğunu bilirik, amma indi funksiyanı işə salmaq daha vacibdir — növbəti sprintdə testlər üçün tapşırıq açacayıq". Birincisi dərhal müdaxilə tələb edir, ikincisi — nəzarət.

Boy Scout Rule strategiyası — "düşərgə yerini tapdığından təmiz burax". Sadə qayda: metodu dəyişdirərkən 10% daha çox vaxt sərf edərək onu bir az yaxşılaşdır — dəyişənin adını dəyiş, 50 sətirlik bloku ikiyə böl. Komanda miqyasında bu yanaşma refaktorinq üçün ayrı sprintlər ayırmadan borcun tədricən azalmasını verir. Yaxşılaşdırma mikroskopik, lakin müntəzəm olmalıdır.

Vaxt ayrılması borcun idarə edilməsi üçün — komandanın yetkinlik göstəricisidir. Sprintin 15–20%-nin texniki yaxşılaşdırmalara ayrılması tövsiyə olunur. Bu o demək deyil ki, komanda həftədə 1 gün refaktorinqdən başqa heç nə etmir. Texniki tapşırıqlar bərabər paylanır: metrikaların yaxşılaşdırılması, isti hissələrin refaktorinqi, asılılıqların yenilənməsi. Ayrılmış vaxt olmadan borc fasiləsiz olaraq artır.

// Boy Scout Rule strategiyası fəaliyyətdə
// İdi: sehrli nömrələrlə oxunmayan metod
fun calc(a: Int): Int = a * 60 * 1000

// Oldu: sabitlərlə oxunan metod
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

Avtomatlaşdırma borcun aşkarlanması — idarəetmənin üçüncü sütunudur. Uzun metodların (>30 sətir), siniflərin (>500 sətir), həddindən artıq iç-içəliyin (>5 səviyyə) aşkarlanması üçün bildirişlər qurun. Pull-requestlərdə avtomatik şərhlər üçün Danger və ya analoqlarından istifadə edin: əgər metod mürəkkəblik həddini aşarsa, bot yazır "Bu metodun siklotomik mürəkkəbliyi 12-dir — zəhmət olmasa bölməyi nəzərdən keçirin". Avtomatlaşdırma kod nəzərdən keçirmə yükünü azaldır.

Borc təhlili üçün alətlər

SonarQube — texniki borcun təhlili üçün ən populyar platformadır. "Düzəltmə üçün günlərin sayı" metrikasını hesablayır — menecerlər üçün anlaşılan ölçü. SonarQube Kotlin, Swift, Java, Python və digər dilləri dəstəkləyir. CI/CD pipeline-a inteqrasiya olunur və borc həddi aşarsa, pull-requesti buraxmır. Mobil komandalar üçün bu de-fakto standartdır.

Android komandaları üçün həmçinin Detekt (Kotlin statik təhlili) və Android Lint istifadə olunur. Detekt kod metrikalarını hesablayır və Code Smell naxışlarını tapır. SonarQube Android Gradle plagin nəticələri vahid hesabata birləşdirir. iOS komandaları üçün — statik təhlil üçün SwiftLint və istifadə olunmayan kodu tapmaq üçün Periphery. Xcode Organizer performans metrikalarını göstərir ki, bunlar tez-tez arxitektura borcu ilə əlaqəlidir.

CodeClimate və CodeFactor — GitHub/GitLab repozitoriyalarını təhlil edən və borc dinamikasını göstərən bulud həlləridir. Hər commit-i qiymətləndirir, borcun nə vaxt artmağa başladığını izləməyə imkan verir. Maintainability qrafiki — rəhbərliklə ünsiyyət üçün anlaşılan alət: "mart ayında pik görürsən? Bu, buraxılışı məcbur etdik və 3 gün düzəltmə borc yığdıq".