Jank dastur ishlab chiqishda — bu nima, junk-kod nimadan zararli va uni qanday olib tashlash kerak

Jank nima?

Jank (junk code) — loyihada mavjud bo'lgan, ammo funksional qiymatga ega bo'lmagan kod, konfiguratsiyalar va bog'liqliklar uchun umumiy atama. Jank albatta buzilgan yoki ishlatilmaydigan degani emas — muammo shundaki, uning mavjudligi loyiha ko'rsatkichlarini adekvat asossiz yomonlashtiradi.

Jank to'rt toifaga bo'linadi. Birinchisi — ortiqcha bog'liqliklar: standart vositalar bilan amalga oshirilishi mumkin bo'lgan bitta funksiya uchun ulangan kutubxonalar. Ikkinchisi — o'lik yuk: sharhlangan bloklar, ticketsiz TODO-lar, bo'sh metodlar va stublar. Uchinchisi — takrorlanuvchi yechimlar: bir xil ishni bajaradigan ikkita kutubxona (masalan, bir loyihada Gson va Kotlin Serialization). To'rtinchisi — over-engineering: ishlatilmaydigan, lekin kelajak uchun saqlanadigan arxitektura qatlamlari.

Stripe Engineering Productivity (2025) tadqiqotiga ko'ra, odatdagi loyihadan 10 foiz jankni olib tashlash to'liq qurilish vaqtini o'rtacha 22 foizga qisqartiradi. Sababi: har bir ortiqcha bog'liqlik qurilish grafigini oshiradi, har bir bo'sh abstraksiya tushunish vaqtini talab qiladi, har bir sharhlangan blok diqqatni chalg'itadi.

Jank bilan kurashishdagi asosiy qiyinchilik — zudlik bilan oqibatlarning yo'qligi. Junk-kodli loyiha kompilyatsiya qilinadi va ishlaydi. Muammolar asta-sekin to'planadi: qurilish sekinlashadi, tranzitiv bog'liqliklar soni ortadi va bir yildan so'ng yangi funksiya qo'shish kerak bo'lganidan ikki baravar ko'p vaqt oladi.

Junk-bog'liqliklar va ularni qanday aniqlash

Junk-bog'liqliklar — bu loyihaga ulangan, lekin kodda to'g'ridan-to'g'ri ishlatilmaydigan yoki faqat standart API-lar bilan osonroq amalga oshiriladigan bitta funksiyada ishlatiladigan kutubxona va paketlardir.

Oddiy misollar: loyiha allaqachon Kotlin Serialization-dan foydalanayotganda JSON uchun kutubxona (ikki parser — bu jank); bitta StringUtils.isEmpty metodi uchun Apache Commons Lang kutubxonasi, Kotlin extension isNullOrBlank bilan almashtirilishi mumkin; o'nta moduldan bittasida ishlatiladigan DI kutubxonasi, qolganlari bog'liqliklarni qo'lda konstruktor orqali oladi.

Har bir ortiqcha bog'liqlik faqat binary-da ortiqcha kod emas. Bu zaifliklar uchun hujum sathining oshishidir: GitHub Advisory Database (2025) ma'lumotlariga ko'ra, mobil loyihalardagi kritik CVE-larning 40 foizi dasturchilar nazorat qilmaydigan tranzitiv bog'liqliklarga to'g'ri keladi. Bog'liqliklar qancha kam bo'lsa — hujum sathi shuncha kichik.

Android loyihasi bog'liqliklarini tahlil qilish

// Gradle bog'liqlik daraxtini ko'rish
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Ishlatilmaydigan bog'liqliklarni topish (Gradle plagini)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Ishlatilmaydigan kutubxonalar hisobotini yaratish
./gradlew buildHealth

iOS uchun to'liq bog'liqlik daraxtini ko'rsatadigan swift package show-dependencies buyrug'idan foydalaning. Xcode Build Timeline vositasi har bir kutubxona qurilishga qancha vaqt qo'shishini ko'rsatadi. Agar kutubxona kompilyatsiya vaqtining 30 foizini olsa, lekin bitta ekranda ishlatilsa — bu olib tashlash yoki almashtirish uchun nomzod.

Node.js (React Native) uchun depcheck — package.json da ishlatilmaydigan bog'liqliklarni topadigan vosita va qo'shimcha ravishda eskirgan versiyalarni ko'rsatadigan npm-check dan foydalaning. Qoida joriy qiling: har bir yangi bog'liqlik code review-dan o'tishi va nima uchun standart vositalar bilan mumkin emasligi asoslanishi kerak.

O'lik importlar va sharhlangan kod

O'lik importlar — eng keng tarqalgan jank turi. Ular run-time ga ta'sir qilmaydi, lekin kompilyatsiya vaqtini oshiradi: kompilyator har bir importni, hatto ishlatilmasa ham, qayta ishlaydi. Katta loyihalarda ishlatilmaydigan importlarni olib tashlash qurilish vaqtini 5–10 foizga qisqartiradi.

Zamonaviy IDE-lar ishlatilmaydigan importlarni avtomatik kulrang rangda ajratib ko'rsatadi. Faylni saqlashda avtomatik tozalashni sozlang: IntelliJ IDEA da — Optimize Imports on the fly, Xcode da — Editor > Remove Unused Imports. CI ga tekshirish qo'shing: linter ishlatilmaydigan importlari bo'lgan commit-larni bloklashi kerak.

Sharhlangan kod — jankning yana bir turi. Dasturchilar refaktoring paytida funksionallikni yo'qotmaslik uchun bloklarni sharhlaydilar. Biroq git o'zgarishlarning to'liq tarixini saqlaydi: har qanday o'chirilgan kodni bitta git revert yoki git log -S buyrug'i bilan tiklash mumkin. Master-da sharhlangan kod jamoaga hurmatsizlikdir: har bir dasturchi aqliy energiyani bu nima uchun sharhlangan va qachon ochilishi kerak degan savolga sarflaydi.

Qoida: repozitoriyda sharhlangan kod yo'q. Agar kod kerak bo'lmasa — uni butunlay o'chiring. Agar kod kerak bo'lsa, lekin vaqtincha o'chirilgan bo'lsa — ticket va muddat bilan feature toggle dan foydalaning. // TODO: remove after migration turidagi sharhlarni muddatsiz qoldirmang. Sana qo'ying va kalendarda eslatma o'rnating.

Ortiqcha abstraksiyalar va over-engineering

Over-engineering — joriy muammolarni hal qilmaydigan, lekin texnik xizmat ko'rsatishni talab qiladigan arxitektura qatlamlarini yaratishdir. Bu jankning eng qiyin turlaridan biri, chunki rasmiy ravishda kod to'g'ri: SOLID ga mos keladi, testlar bilan qoplangan va arxitekturaga mos keladi. Muammo shundaki, unga ehtiyoj yo'q.

Klassik misol — faqat repozitoriyani chaqiradigan bitta invoke metodi bilan abstrakt UseCase klassi. Agar UseCase mantiq qo'shmasa (keshlash, retry, transformatsiya), faqat chaqiruvni uzatsa — bu ortiqcha mavjudotdir. Loyiha bo'ylab navigatsiyani oshiradi: dasturchi UseCase ni ochadi, invoke → repository ni ko'radi va yopadi. Vaqt behuda, foyda nol.

Yana bir misol — ortiqcha parametrlash. Bir joyda ishlatiladigan oltita type parametrli generic-interfeys. Har bir type parametr kognitiv yukdir: kodni o'qiyotganda oltita turni esda saqlash kerak, haqiqatda faqat ikkitasi ishlatilsa ham. Agar abstraksiya qayta ishlatilmasa — ortiqcha.

Kesish mezoni: agar abstraksiya uch xil kontekstda qayta ishlatilmasa — uni olib tashlang. Abstraksiya takrorlanish muammosini real hal qilganda oqlanadi, faraziy kelajak stsenariylarini bashorat qilganda emas. YAGNI (You Ain't Gonna Need It) — over-engineering ning oldini olishning eng yaxshi prinsipi.

Jank audit vositalari

Jank auditi statik tahlil, bog'liqlik tahlili va qo'lda tekshirishning kombinatsiyasini talab qiladi. Ortiqcha abstraksiyalarni qidirishni to'liq avtomatlashtirish mumkin emas, lekin texnik jank (o'lik importlar, ishlatilmaydigan kutubxonalar, sharhlangan kod) vositalar bilan topiladi.

To'liq audit uchun har sprintda buildHealth (Android) yoki depcheck (Node.js) ni ishga tushiring. CI da bog'liqliklar sonining sprintlar bo'yicha dinamikasini ko'rsatadigan dashboard yarating. Agar son oshsa, funksionallik esa mutanosib oshmasa — jamoa jank to'playapti.

Duplicate classes — ikkita kutubxona bir xil sinfni o'z ichiga olgan xatoga e'tibor bering. Bu nafaqat jank, balki qurilish konfliktlarining bevosita manbai. Gradle da bunday konfliktlar force yoki exclude orqali hal qilinadi, lekin har bir bunday hal qilish kutubxonalardan biri ortiqcha ekanligining signalidir.

Loyihani muntazam tozalash jarayoni

Jankni tozalash bir martalik aksiya emas, balki muntazam jarayondir. Qoidalarsiz jank ikki-uch sprint ichida qaytadi. Eng yaxshi amaliyot — har bir sprintning 10–15 foiz sig'imini texnik tozalashga, jumladan jank auditiga ajratish.

Jarayon to'rt bosqichdan iborat. Birinchisi — diagnostika: vositalarni ishga tushirish, hisobot olish, ustuvorlikni belgilash. Yuqori ustuvorlik — ma'lum CVE li bog'liqliklar va takrorlanuvchi kutubxonalar. O'rta — o'lik importlar va sharhlangan kod. Past — ortiqcha abstraksiyalar (qo'lda tahlil talab qiladi).

Ikkinchisi — tozalash: o'lik bog'liqliklarni olib tashlash, takrorlanuvchi kutubxonalarni bittasi bilan almashtirish, sharhlangan kodni olib tashlash. Har bir o'zgarish tushunarli message bilan alohida commit da amalga oshiriladi: «remove unused dependency: gson (replaced by kotlinx.serialization)», «delete commented code in LoginViewModel».

Uchinchisi — tekshirish: loyihani qurish, testlarni ishga tushirish, UI ni tekshirish. Agar bog'liqlikni olib tashlagandan so'ng testlar o'tsa — bog'liqlik haqiqatan ham kerak emas edi. Agar testlar yiqilsa — statik analizator aniqlamagan yashirin havola qolgan.

To'rtinchisi — profilaktika: code review checklist ini yangilash, Definition of Doonga asossiz yangi bog'liqliklarni taqiqlash qoidasini qo'shish, CI da avtomatik tekshirishni sozlash. Profilaktika jankning qayta to'planishining oldini olishning yagona usulidir.