Dasturlashda o'lik kod va zombi kod: bu nima, sabablari va qidirish

O'lik kod nima?

O'lik kod (dead code) — dasturga kiritilgan, ammo hech qanday foydalanish stsenariysida bajarilmaydigan manba kodi. Kompilyator yoki interpretator uni qayta ishlaydi, ammo bajarish vaqtida boshqaruv hech qachon bu qismlarga o'tmaydi.

O'lik kodning klassik misollari: qiymat berilgan, ammo hech qachon o'qilmaydigan o'zgaruvchilar; hech qayerda chaqirilmaydigan funksiyalar yoki metodlar; hech qachon rost bo'lmaydigan shart tarmoqlari (if(false)); tanasi bir marta ham bajarilmaydigan sikllar.

SonarQube State of Code Quality (2025) hisobotiga ko'ra, tijorat Java loyihalaridagi barcha ogohlantirishlarning taxminan 15 foizi foydalanilmayotgan private metodlar va maydonlar bilan bog'liq. JavaScript loyihalarida foydalanilmayotgan kodning ulushi 30 foizga yetishi mumkin, bu tilning dinamik tabiati va uchinchi tomon kutubxonalarining ko'pligi bilan bog'liq.

Loyihani muntazam ravishda o'lik kod mavjudligi uchun tekshiring — ayniqsa katta refaktoringlar va funksiyalarni o'chirishdan so'ng. Bugun unutilgan import yoki foydalanilmayotgan funksiya ertaga jamoaning yangi a'zolarini chalg'itadigan zombi kodga aylanishi mumkin.

O'lik kod va zombi kod o'rtasidagi farqlar

Zombi kod (zombie code) — tarixiy kontekst bilan ajralib turadigan o'lik kodning alohida holatidir. Zombi kod bir vaqtlar ishlagan, ammo tizimdagi o'zgarishlardan so'ng erishib bo'lmaydigan bo'lib qolgan, shunga qaramay uni o'chirishmagan, balki "har ehtimolga qarshi" qoldirishgan.

O'lik kod va zombi kod o'rtasidagi farq kelib chiqishidadir. O'lik kod xato bilan yozilgan bo'lishi mumkin (hech qachon ishlamagan), zombi kod esa refaktoring paytida dolzarbligini yo'qotgan sobiq tirik koddir. Masalan, yangisi bilan almashtirilgan eski biznes mantiqiga asoslangan chegirma hisoblash funksiyasi — eski metodni o'chirishmadi, qaytarish kerak bo'lsa degan umidda.

Zombi kodning asosiy xavfi — ishlayotgan funksionallik illyuziyasidir. Yangi dasturchi funksiyani ko'radi, hujjatlarini o'qiydi, u qayerdadir chaqiriladi deb taxmin qiladi — va artefaktni o'rganishga vaqt sarflaydi. Uni to'g'ridan-to'g'ri chaqirishga urinayotganda, u o'chirilgan ob'ektlarga yoki eskirgan API-larga bog'liqligi ma'lum bo'lishi mumkin.

Zombi kodni git tarixi orqali kuzatib boring: agar funksiya ikki yil davomida o'zgarmagan va ishlatilmayotgan bo'lsa — bu zombi. Uni ikkilanmasdan o'chiring, chunki git tarixni saqlaydi va kerak bo'lganda kodni har doim tiklash mumkin.

O'lik kodning paydo bo'lish sabablari

Birinchi va eng keng tarqalgan sabab — to'liq bo'lmagan refaktoring bilan iterativ ishlab chiqish. Jamoa eskisini almashtiradigan yangi funksionallik qo'shadi, ammo almashtirilgan modullarni o'chirmaydi. Sprintlar bunday "dumlarni" to'playdi va bir yildan so'ng loyiha o'lik kod qatlami bilan qoplanadi.

Ikkinchi sabab — A/B testlash va feature toggle. Yangi funksiyani yoqish shartlari vaqt o'tishi bilan barqarorlashishi mumkin (masalan, har doim true), ammo muqobil mantiq bilan else tarmog'i kodda qoladi. Dasturchilar toggle qayta o'zgartirilsa, tasodifan tizimni buzmaslik uchun uni o'chirishga qo'rqadilar.

Uchinchi sabab — avtomatik yaratish va copy-paste. Kod generatorlari (IDE, shablonlashtirgichlar) dasturchi to'ldirmaydigan yoki ishlatmaydigan metodlar bilan shablonlar yaratadi. Boshqa loyihadan ko'chirilgan kod ko'pincha yangi kontekstga aloqador bo'lmagan butun bloklarni o'z ichiga oladi.

To'rtinchi sabab — o'chirishdan qo'rqish. Katta loyihalarda dasturchilar kodni o'chirishdan qo'rqadilar, chunki u haqiqatan ham hech qayerda ishlatilmasligiga ishonchlari komil emas. Bu qo'rquv zaif test tizimi bilan kuchayadi: agar avtomatik tekshirish bo'lmasa, o'chirish faqat ishlab chiqarishda aniqlanadigan xatolarga olib kelishi mumkin.

O'lik kodning xavflari

O'lik kod loyiha sifatining to'rt jihatiga bevosita ta'sir qiladi: yig'ish samaradorligi, artefakt hajmi, jamoaning kognitiv yuki va refaktoring ishonchliligi.

Kompilyatsiya vaqtining oshishi: kompilyator foydalanilmayotgan fayllarni qayta ishlaydi, bog'liqliklarni tahlil qiladi va hech qachon ishga tushmaydigan bo'laklar uchun baytkod yoki mashina kodini yaratadi. Katta loyihalarda bu har bir yig'ishga daqiqalar qo'shadi. Interpretatsiya qilinadigan tillar uchun (JavaScript, Python) modulni yuklash vaqti va xotira iste'moli ortadi.

O'zgartirish paytida xato xavfi: dasturchi kodni o'zgartirganda, funksiya faqat o'lik tarmoqda ishlatilishini bilmaydi. Refaktoringdan so'ng o'lik kod kompilyatsiya qilinmaydi yoki xatolar beradi — jamoa ilova ishiga ta'sir qilmaydigan muammoni diagnostika qilishga vaqt sarflaydi.

Kognitiv yuk — eng qimmat omil. Har bir foydalanilmayotgan funksiya kodni o'qiyotganda diqqat talab qiladi. Dasturchi bu kod nima uchun mavjudligi va qayerda chaqirilishini tushunish uchun aqliy energiya sarflaydi. Developer Productivity Lab (2025) tadqiqoti shuni ko'rsatdi: o'lik kodning 20 foizini o'chirish jamoada ish boshlash vaqtini (onboarding time) o'rtacha 18 foizga qisqartiradi.

O'lik kodni aniqlaganingizdan so'ng darhol o'chiring. Har bir kechikish kuni jamoa a'zolaridan biri kecha o'chirilishi kerak bo'lgan artefaktni o'rganishga soatlar sarflash ehtimolini oshiradi.

O'lik kodni qidirish vositalari

O'lik kodni qidirish ikkita asosiy usul bilan amalga oshiriladi: statik tahlil (dasturni ishga tushirmasdan) va dinamik tahlil (bajarish vaqtida qamrovni profillash). Har bir yondashuv turli xil o'lik kod turlari uchun samarali.

Statik analizatorlar barcha mashhur dasturlash tillarini qo'llab-quvvatlaydi. Java va Kotlin uchun — SonarQube, IntelliJ IDEA Inspections, SpotBugs. JavaScript va TypeScript uchun — ESLint no-unused-vars va no-unused-modules qoidalari bilan. Swift uchun — SwiftLint unused_declaration qoidasi bilan. Python uchun — pylint unused-import opsiyasi bilan va chuqur qidirish uchun vulture.

ProGuard orqali Kotlin-da qidirish misoli

// build.gradle.kts — Android uchun ProGuard konfiguratsiyasi
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro — faqat kerakli sinflarni saqla
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard nafaqat foydalanilmayotgan sinflar va metodlarni o'chiradi, balki release yig'masida nomlarni minifikatsiya qiladi. ProGuard yoqilgan yig'ma avtomatik ravishda qaysi sinflar va metodlar foydalanilmayotgan deb hisoblanishini ko'rsatadi — usage.txt hisobotida barcha o'chirilgan kod sanab o'tilgan.

Test qamrovi orqali dinamik tahlil

Kod qamrovi vositalari (Java uchun JaCoCo, Swift uchun XCTest coverage, JavaScript uchun Istanbul) testlar paytida qaysi qatorlar va tarmoqlar bajarilishini ko'rsatadi. Nol qamrovga ega metodlar o'lik kod nomzodlaridir. Biroq, qamrovning yo'qligi kod ishlab chiqarishda chaqirilmasligini kafolatlamaydi — to'liq ishonch uchun statik va dinamik tahlil kombinatsiyasidan foydalaning.

CI pipeline-ni shunday sozlangki, foydalanilmayotgan deklaratsiyalar chegarasi oshib ketganda yig'ma muvaffaqiyatsiz bo'lsin. "Foydalanilmayotgan private kod ulushi 3% dan oshmasin" qoidasi bilan SonarQube Quality Gate ishlab chiqish jarayoni darajasida o'lik kod to'planishining oldini oladi.

O'lik kodni qanday xavfsiz o'chirish mumkin

O'lik kodni o'chirish jarayoni to'rt qadamdan iborat: topish, tekshirish, o'chirish, qayta tekshirish. Har qanday qadamni o'tkazib yuborish regressiya xavfini oshiradi.

Birinchi qadam — nomzodlarni qidirish statik analizator orqali. Foydalanilmayotgan deklaratsiyalar haqida hisobot oling: funksiyalar, sinflar, o'zgaruvchilar, importlar. Soxta ijobiy natijalarni filtrlash — analizatorlar ba'zan refleksiya, sinflarni dinamik yuklash yoki serializatsiya orqali yashirin chaqiruvlarda xato qiladi.

Ikkinchi qadam — git blame va o'zgarishlar tarixi orqali tekshirish. Kodning qachon va nima uchun yozilganini ko'rib chiqing. Agar kod feature toggle bilan o'chirilgan funksiyaning bir qismi bo'lsa, toggle barqarorlashganiga va qayta yoqilmasligiga ishonch hosil qiling. O'chirishga shubha qiladigan kodni izohga oling va bir oydan so'ng qayta tekshirish uchun TODO bilan topshiriq qoldiring.

Uchinchi qadam — alohida tarmoqda o'chirish va to'liq testlar to'plamini ishga tushirish. Agar testlar o'tsa — regressiya ehtimoli past. Agar testlar muvaffaqiyatsiz bo'lsa — kod hali ham ishlatilayotganligini anglatadi va qaysi stsenariyda ekanligini aniqlash kerak.

// oldin — bir faylda o'lik kod va zombi kod
int calculateV1(int price) { // hech qayerda chaqirilmaydi
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// keyin — o'lik kod o'chirildi, zombi kod tozalandi
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

To'rtinchi qadam — o'zgartirishlarni code review qilish. Sharhlovchi kod haqiqatan ham o'lik ekanligini tasdiqlashi kerak. Agar sharhlovchi ishonchli bo'lmasa — kodda izoh qoldiring va to'liq tahlilgacha o'chirishni kechiktiring. Tarmoq birlashtirilgandan so'ng, tarmoqni o'chiring — git repozitoriyasida zombi kod ko'paymasligi uchun.

Bir qoida joriy qiling: hech bir pull request yangi o'lik kodni o'z ichiga olmasligi kerak. Foydalanilmayotgan o'zgaruvchilar yoki importlar mavjud bo'lganda commit-ni bloklaydigan pre-commit hook-lariga linter qo'shing. Profilaktika har doim tozalashdan arzonroq.