Jank proqramlaşdırmada — bu nədir, junk-kod nə üçün zərərlidir və onu necə təmizləmək olar

Jank nədir?

Jank (junk code) — layihədə mövcud olan, lakin funksional dəyər daşımayan kod, konfiqurasiyalar və asılılıqlar üçün ümumi termindir. Jank mütləq sınmış və ya istifadə olunmamır — problem ondadır ki, onun mövcudluğu layihənin metrikalarını adekvat əsaslandırma olmadan pisləşdirir.

Jank dörd kateqoriyaya bölünür. Birinci — artıq asılılıqlar: standart vasitələrlə reallaşdırıla bilən bir funksiya üçün qoşulmuş kitabxanalar. İkinci — ölü yük: şərhə alınmış bloklar, ticket-siz TODO-lar, boş metodlar və stub-siniflər. Üçüncü — təkrarlanan həllər: eyni işi görən iki kitabxana (məsələn, eyni layihədə Gson və Kotlin Serialization). Dördüncü — over-engineering: istifadə olunmayan, lakin gələcək üçün saxlanılan memarlıq qatları.

Stripe Engineering Productivity (2025) tədqiqatına görə, tipik layihədən 10 faiz jankın silinməsi tam qurulma vaxtını orta hesabla 22 faiz azaldır. Səbəb: hər artıq asılılıq qurulma qrafını artırır, hər boş abstraksiya anlama vaxtı tələb edir, hər şərhə alınmış blok diqqəti yayındırır.

Jankla mübarizədə əsas çətinlik dərhal nəticələrin olmamasıdır. Junk-kodu olan layihə kompilyasiya olunur və işləyir. Problemlər tədricən yığılır: qurulma yavaşlayır, tranzitiv asılılıqların sayı artır, bir ildən sonra yeni funksiya əlavə etmək lazım olduğundan iki dəfə çox vaxt aparır.

Junk-asılılıqlar və onları necə aşkar etmək olar

Junk-asılılıqlar — layihəyə qoşulmuş, lakin kodda birbaşa istifadə olunmayan və ya yalnız standart API-lərlə daha asan reallaşdırıla bilən bir funksiyada istifadə olunan kitabxana və paketlərdir.

Tipik nümunələr: layihə artıq Kotlin Serialization istifadə edərkən JSON üçün kitabxana (iki parser — bu jankdır); bir StringUtils.isEmpty metodu üçün Apache Commons Lang kitabxanası, Kotlin extension isNullOrBlank ilə əvəz oluna bilər; on moduldan birində istifadə olunan DI kitabxanası, qalanları asılılıqları əl ilə konstruktor vasitəsilə alır.

Hər artıq asılılıq yalnız binar faylda artıq kod deyil. Bu, zəifliklər üçün hücum səthinin artırılmasıdır: GitHub Advisory Database (2025) məlumatına görə, mobil layihələrdə kritik CVE-lərin 40 faizi proqramçıların nəzarət etmədiyi tranzitiv asılılıqlara düşür. Nə qədər az asılılıq — bir o qədər kiçik hücum səthi.

Android layihəsinin asılılıqlarının təhlili

// Gradle asılılıq ağacına bax
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// İstifadə olunmayan asılılıqları tap (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// İstifadə olunmayan kitabxana hesabatı yarat
./gradlew buildHealth

iOS üçün tam asılılıq ağacını göstərən swift package show-dependencies əmrindən istifadə edin. Xcode Build Timeline aləti hər kitabxananın qurulmaya nə qədər vaxt əlavə etdiyini göstərir. Əgər kitabxana kompilyasiya vaxtının 30 faizini tutursa, ancaq bir ekranda istifadə olunursa — bu, silinməyə və ya dəyişdirilməyə namizəddir.

Node.js (React Native) üçün depcheck — package.json-da istifadə olunmayan asılılıqları tapan alət və əlavə olaraq köhnəlmiş versiyaları göstərən npm-check istifadə edin. Qayda tətbiq edin: hər yeni asılılıq code review-dən keçməli və niyə standart vasitələrlə mümkün olmadığı əsaslandırılmalıdır.

Ölü importlar və şərhə alınmış kod

Ölü importlar — ən geniş yayılmış jank növüdür. Onlar run-time-a təsir etmir, lakin kompilyasiya vaxtını artırır: kompilyator hər importu, hətta istifadə olunmasa belə, emal edir. Böyük layihələrdə istifadə olunmayan importların silinməsi qurulma vaxtını 5–10 faiz azaldır.

Müasir IDE-lər istifadə olunmayan importları avtomatik boz rənglə vurğulayır. Faylı yaddaşda avtomatik təmizləməni qurun: IntelliJ IDEA-da — Optimize Imports on the fly, Xcode-da — Editor > Remove Unused Imports. CI-ə yoxlama əlavə edin: linter istifadə olunmayan importları olan commit-ləri bloklamalıdır.

Şərhə alınmış kod — başqa bir jank növüdür. Proqramçılar refaktoring zamanı funksionallığı itirməmək üçün blokları şərhə alırlar. Lakin git dəyişikliklərin tam tarixini saxlayır: silinmiş istənilən kodu bir git revert və ya git log -S əmri ilə bərpa etmək olar. Master-da şərhə alınmış kod komandaya hörmətsizlikdir: hər proqramçı zehni enerjini bu kodun nə üçün şərhə alındığı və nə vaxt açılmalı olduğu sualına sərf edir.

Qayda: repozitoridə şərhə alınmış kod yoxdur. Kod lazım deyilsə — onu həmişəlik silin. Kod lazımdırsa, lakin müvəqqəti söndürülübsə — ticket və müddətlə feature toggle istifadə edin. // TODO: remove after migration tipli şərhləri deadline-sız qoymayın. Tarix qoyun və təqvimdə xatırladıcı təyin edin.

Artıq abstraksiyalar və over-engineering

Over-engineering — cari problemləri həll etməyən, lakin dəstək tələb edən memarlıq qatlarının yaradılmasıdır. Bu, jankın ən çətin növlərindən biridir, çünki formal olaraq kod düzgündür: SOLID-ə uyğundur, testlərlə əhatə olunub və memarlığa uyğundur. Problem ondadır ki, ona ehtiyac yoxdur.

Klassik nümunə — sadəcə repozitoriyi çağıran bir invoke metodu olan abstrakt UseCase sinfi. UseCase məntiq əlavə etmirsə (keşləmə, retry, transformasiya), ancaq çağırışı ötürürsə — bu artıq varlıqdır. Layihədə naviqasiyanı artırır: proqramçı UseCase-ni açır, invoke → repository görür və bağlayır. Vaxt itirilib, fayda sıfır.

Başqa nümunə — artıq parametrləşdirmə. Bir yerdə istifadə olunan altı type parametrli generic-interfeys. Hər type parameter idrak yüküdür: kodu oxuyarkən altı tipi yadda saxlamaq lazımdır, halbuki real olaraq yalnız ikisi istifadə olunur. Abstraksiya təkrar istifadə olunmursa — artıqdır.

Kəsmə meyarı: abstraksiya üç fərqli kontekstdə təkrar istifadə olunmursa — onu silin. Abstraksiya, dublikasiya problemini real həll etdikdə əsaslandırılır, hipotetik gələcək ssenariləri proqnozlaşdırdıqda yox. YAGNI (You Ain't Gonna Need It) — over-engineering-in qarşısının alınmasının ən yaxşı prinsipidir.

Jank auditi alətləri

Jank auditi statik analiz, asılılıq analizi və əl ilə yoxlamanın kombinasiyasını tələb edir. Artıq abstraksiyaların axtarışını tam avtomatlaşdırmaq mümkün deyil, lakin texniki jank (ölü importlar, istifadə olunmayan kitabxanalar, şərhə alınmış kod) alətlərlə tapılır.

Tam audit üçün hər sprintdə buildHealth (Android) və ya depcheck (Node.js) işə salın. CI-də asılılıqların sayının sprintlər üzrə dinamikasını göstərən dashboard yaradın. Əgər say artır, funksionallıq isə mütənasib artmırsa — komanda jank toplayır.

Duplicate classes — iki kitabxananın eyni sinfi ehtiva etdiyi xətaya diqqət yetirin. Bu təkcə jank deyil, həm də qurulma konfliktlərinin birbaşa mənbəyidir. Gradle-da belə konfliktlər force və ya exclude ilə həll olunur, lakin hər belə həll kitabxanalardan birinin artıq olduğuna işarədir.

Layihənin müntəzəm təmizlənməsi prosesi

Jankın təmizlənməsi birdəfəlik aksiya deyil, müntəzəm prosesdir. Qaydalar olmadan jank iki-üç sprint ərzində qayıdır. Ən yaxşı təcrübə — hər sprintin 10–15 faiz tutumunu texniki təmizləməyə, o cümlədən jank auditinə ayırmaqdır.

Proses dörd addımdan ibarətdir. Birinci — diaqnostika: alətlərin işə salınması, hesabatın alınması, prioritetləşdirmə. Yüksək prioritet — məlum CVE-li asılılıqlar və təkrarlanan kitabxanalar. Orta — ölü importlar və şərhə alınmış kod. Aşağı — artıq abstraksiyalar (əl ilə analiz tələb edir).

İkinci — təmizləmə: ölü asılılıqların silinməsi, təkrarlanan kitabxanaların biri ilə əvəz edilməsi, şərhə alınmış kodun silinməsi. Hər dəyişiklik ayrı commit-lə başa düşülən mesajla edilir: «remove unused dependency: gson (replaced by kotlinx.serialization)», «delete commented code in LoginViewModel».

Üçüncü — verifikasiya: layihənin qurulması, testlərin işə salınması, UI-nin yoxlanması. Əgər asılılığı sildikdən sonra testlər keçirsə — asılılıq həqiqətən lazım deyildi. Testlər düşürsə — hardasa statik analizatorun aşkar etmədiyi gizli istinad qalıb.

Dördüncü — profilaktika: code review checklist-inin yenilənməsi, Definition of Done-a əsaslandırılmamış yeni asılılıqların qadağan edilməsi qaydasının əlavə edilməsi, CI-də avtomatik yoxlamanın qurulması. Profilaktika jankın yenidən yığılmasının qarşısını almağın yeganə yoludur.