Ölü kod — proqramın heç vaxt icra olunmayan və nəticəyə təsir etməyən, lakin fiziki olaraq layihənin mənbə kodlarında qalan fraqmentləridir. Şərhə salınmış hissələrdən fərqli olaraq, ölü kod kompilyasiya olunur və binar fayla daxil olur, ölçüsünü artırır və naviqasiyanı çətinləşdirir. TIOBE Index (2025) araşdırmasına görə, orta kommersiya layihəsində heç vaxt çağrılmayan kodun payı 10-25 faiz təşkil edir. Zombi kodu — keçmişdə işləyən, lakin refaktorinqdən sonra aktuallığını itirərək sadəcə yer tutan ölü kodun alt növüdür. Belə fraqmentlərin müntəzəm təmizlənməsi proqramçıların idrak yükünü azaldır və dəyişikliklər edilərkən səhv riskini minimuma endirir.
Əsas məqamlar
Ölü kod (dead code) — proqrama daxil edilmiş, lakin heç bir istifadə ssenarisində icra olunmayan mənbə kodudur. Kompilyator və ya interpretator onu emal edir, lakin icra zamanı idarəetmə heç vaxt bu hissələrə düşmür.
Ölü kodun klassik nümunələri: dəyər təyin edilmiş, lakin heç vaxt oxunmayan dəyişənlər; heç yerdə çağrılmayan funksiyalar və ya metodlar; heç vaxt doğru olmayan şərt budaqları (if(false)); gövdəsi heç vaxt icra olunmayan dövrlər.
SonarQube State of Code Quality (2025) hesabatına görə, kommersiya Java layihələrindəki bütün xəbərdarlıqların təxminən 15 faizi istifadə olunmayan private metodlar və sahələrlə bağlıdır. JavaScript layihələrində dilin dinamik təbiəti və çoxsaylı üçüncü tərəf kitabxanaları səbəbindən istifadə olunmayan kodun payı 30 faizə çata bilər.
Layihəni mütəmadi olaraq ölü kodun olub-olmaması üçün yoxlayın — xüsusilə böyük refaktorinqlər və funksiyaların silinməsindən sonra. Bu gün unudulmuş bir import və ya istifadə olunmayan funksiya sabah komandanın yeni üzvlərini çaşdıran zombi koduna çevrilə bilər.
Zombi kodu (zombie code) — tarixi kontekstə görə fərqlənən ölü kodun xüsusi halıdır. Zombi kodu bir zamanlar işləyirdi, lakin sistemdəki dəyişikliklərdən sonra əlçatmaz oldu, buna baxmayaraq onu silmədilər, "hər ehtimala qarşı" saxladılar.
Ölü kod və zombi kodu arasındakı fərq mənşəyindədir. Ölü kod səhvən yazılmış ola bilər (heç vaxt işləməyib), zombi kodu isə refaktorinq zamanı aktuallığını itirmiş keçmiş canlı koddur. Məsələn, yenisi ilə əvəz edilmiş köhnə biznes məntiqinə əsaslanan endirim hesablama funksiyası — köhnə metodu silmədilər, qaytarmaq lazım olarsa deyə.
Zombi kodunun əsas təhlükəsi — işləyən funksionallıq illüziyasıdır. Yeni proqramçı funksiyanı görür, sənədləşməsini oxuyur, haradasa çağrıldığını güman edir — və artefaktı öyrənməyə vaxt sərf edir. Birbaşa çağırmağa cəhd etdikdə isə onun silinmiş varlıqlardan və ya köhnəlmiş API-lərdən asılı olduğu üzə çıxa bilər.
Zombi kodunu git tarixçəsi vasitəsilə izləyin: əgər funksiya iki ildir dəyişməyibsə və istifadə olunmursa — bu zombidir. Tərəddüd etmədən silin, çünki git tarixçəni saxlayır və lazım gəldikdə kodu həmişə bərpa etmək olar.
Birinci və ən çox rast gəlinən səbəb — natamam refaktorinqlə iterativ inkişafdır. Komanda köhnəni əvəz edən yeni funksionallıq əlavə edir, lakin əvəz edilmiş modulları silmir. Sprintlər belə "quyruqları" toplayır və bir ildən sonra layihə ölü kod təbəqəsi ilə örtülür.
İkinci səbəb — A/B testi və feature toggle. Yeni funksiyanın aktivləşdirilməsi şərtləri zamanla sabitlənə bilər (məsələn, həmişə true), lakin alternativ məntiqlə else budağı kodda qalır. Proqramçılar toggle geri çevrilərsə, təsadüfən sistemi sındırmamaq üçün onu silməyə qorxurlar.
Üçüncü səbəb — avtogenerasiya və copy-paste. Kod generatorları (IDE, şablonlaşdırıcılar) proqramçının doldurmadığı və ya istifadə etmədiyi metodlarla şablonlar yaradır. Başqa layihədən kopyalanmış kod çox vaxt yeni kontekstə aid olmayan bütöv bloklar ehtiva edir.
Dördüncü səbəb — silmək qorxusudur. Böyük layihələrdə proqramçılar kodu silməyə qorxurlar, çünki onun həqiqətən heç yerdə istifadə olunmadığına əmin deyillər. Bu qorxu zəif test sistemi ilə daha da güclənir: avtomatik yoxlama yoxdursa, silmə yalnız istehsalatda aşkarlanacaq səhvlərə səbəb ola bilər.
Ölü kod birbaşa layihə keyfiyyətinin dörd aspektinə təsir edir: yığma performansı, artefakt ölçüsü, komandanın idrak yükü və refaktorinqin etibarlılığı.
Kompilyasiya vaxtının artması: kompilyator istifadə olunmayan faylları emal edir, asılılıqları təhlil edir və heç vaxt işə düşməyəcək fraqmentlər üçün baytkod və ya maşın kodu yaradır. Böyük layihələrdə bu, hər yığmaya dəqiqələr əlavə edir. İnterpretə olunan dillər üçün (JavaScript, Python) modulun yüklənmə vaxtı və yaddaş istehlakı artır.
Dəyişiklik zamanı səhv riski: proqramçı kodu dəyişdirərkən funksiyanın yalnız ölü budaqda istifadə edildiyindən xəbərsizdir. Refaktorinqdən sonra ölü kod kompilyasiya olunmur və ya səhvlər verir — komanda proqramın işinə təsir etməyən problemi diaqnoz etməyə vaxt sərf edir.
İdrak yükü — ən bahalı amildir. Hər bir istifadə olunmayan funksiya kodu oxuyarkən diqqət tələb edir. Proqramçı bu kodun nə üçün mövcud olduğunu və harada çağrıldığını anlamaq üçün zehni enerji sərf edir. Developer Productivity Lab (2025) araşdırması göstərdi: ölü kodun 20 faizinin silinməsi yeni işçilərin layihəyə qoşulma vaxtını (onboarding time) orta hesabla 18 faiz azaldır.
Ölü kodu aşkar edən kimi dərhal silin. Hər gecikmə günü komanda üzvlərindən birinin dünən silinməli olan artefaktı öyrənməyə saatlar sərf etmə ehtimalını artırır.
Ölü kodun axtarışı iki əsas metodla həyata keçirilir: statik analiz (proqramı işə salmadan) və dinamik analiz (icra zamanı əhatənin profilləşdirilməsi). Hər bir yanaşma müxtəlif ölü kod növləri üçün effektivdir.
Statik analizatorlar bütün populyar proqramlaşdırma dillərini dəstəkləyir. Java və Kotlin üçün — SonarQube, IntelliJ IDEA Inspections, SpotBugs. JavaScript və TypeScript üçün — ESLint no-unused-vars və no-unused-modules qaydaları ilə. Swift üçün — SwiftLint unused_declaration qaydası ilə. Python üçün — pylint unused-import seçimi ilə və dərin axtarış üçün vulture.
// build.gradle.kts — Android üçün ProGuard konfiqurasiyası
android {
buildTypes {
release {
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
}
}
// proguard-rules.pro — yalnız tələb olunan sinifləri saxla
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
static <methods>;
}
ProGuard nəinki istifadə olunmayan sinifləri və metodları silir, həm də release yığmasında adları minifikasiya edir. ProGuard aktivləşdirilmiş yığma avtomatik olaraq hansı sinif və metodların istifadə olunmamış hesab edildiyini göstərir — usage.txt hesabatında bütün silinmiş kod sadalanır.
Kod əhatəsi alətləri (Java üçün JaCoCo, Swift üçün XCTest coverage, JavaScript üçün Istanbul) testlər zamanı hansı sətir və budaqların icra olunduğunu göstərir. Sıfır əhatəli metodlar ölü kod namizədləridir. Lakin əhatənin olmaması kodun istehsalatda çağrılmadığına zəmanət vermir — tam əminlik üçün statik və dinamik analizin kombinasiyasından istifadə edin.
CI pipeline-nı elə qurun ki, istifadə olunmayan deklarasiyaların həddi aşıldıqda yığma uğursuz olsun. "İstifadə olunmayan private kodun payı 3%-dən çox deyil" qaydası ilə SonarQube Quality Gate inkişaf prosesi səviyyəsində ölü kodun yığılmasının qarşısını alır.
Ölü kodun silinməsi prosesi dörd addımdan ibarətdir: tap, yoxla, sil, yenidən yoxla. Hər hansı addımın buraxılması reqressiya riskini artırır.
Birinci addım — namizədlərin axtarışı statik analizator vasitəsilə. İstifadə olunmayan deklarasiyalar haqqında hesabat əldə edin: funksiyalar, siniflər, dəyişənlər, importlar. Yalan pozitivləri süzün — analizatorlar bəzən refleksiya, siniflərin dinamik yüklənməsi və ya serializasiya vasitəsilə gizli çağrışlarda səhv edir.
İkinci addım — git blame və dəyişiklik tarixçəsi vasitəsilə yoxlama. Kodun nə vaxt və nə üçün yazıldığına baxın. Əgər kod feature toggle ilə söndürülmüş funksiyanın hissəsi idisə, toggle-in sabitləndiyinə və geri qaytarılmayacağına əmin olun. Silinməsinə şübhə etdiyiniz kodu şərhə salın və bir aydan sonra yenidən yoxlamaq üçün TODO ilə tapşırıq buraxın.
Üçüncü addım — ayrıca budaqda silmə və tam test dəstinin işə salınması. Testlər keçərsə — reqressiya ehtimalı aşağıdır. Testlər uğursuz olarsa — kod hələ də istifadə olunur və hansı ssenaridə olduğunu müəyyən etmək lazımdır.
// əvvəl — eyni faylda ölü kod və zombi kodu
int calculateV1(int price) { // heç yerdə çağrılmayıb
int tax = price * 0.18;
return price + tax;
}
int calculateV2(int price, double rate) {
return static_cast<int>(price * (1 + rate));
}
// sonra — ölü kod silindi, zombi kodu təmizləndi
int calculatePrice(int price, double rate) {
return static_cast<int>(price * (1 + rate));
}
Dördüncü addım — dəyişikliklərin code review-si. Rəyçi kodun həqiqətən ölü olduğunu təsdiqləməlidir. Əgər rəyçi əmin deyilsə — kodda şərh buraxın və tam analizədək silməni təxirə salın. Budaq birləşdirildikdən sonra budağı silin ki, git repozitoriyasında zombi kodu çoxalmasın.
Bir qayda tətbiq edin: heç bir pull request yeni ölü kod ehtiva etməməlidir. İstifadə olunmayan dəyişənlər və ya importlar olduqda commit-i bloklayan pre-commit hook-larına linter əlavə edin. Profilaktika həmişə təmizlikdən daha ucuzdur.
Tez-tez verilən suallar
Bəli, əgər ölü kod sintaksis səhvləri ehtiva edirsə və ya silinmiş tiplərə istinad edirsə. Müasir kompilyatorlar yenə də ölü budaqları yoxlayır, buna görə də if(false) blokundakı səhv yığmanın uğursuz olmasına səbəb olacaq. Bu qorunmadır: kod kompilyatorun yoxlamadığı qədər ölü olmamalıdır.
Zombi kodu çaşqınlıq yaradır: yeni proqramçı sənədləşməsi olan funksiyanı görür və onun istifadə edildiyini güman edir. İşləməyən kodu öyrənməyə vaxt sərf edir və təsadüfən yeni məntiqi köhnəlmiş varlığa bağlaya bilər ki, bu da çətin aşkarlanan xətaya səbəb olar.
ESLint istifadə edin no-unused-vars və no-unused-modules qaydaları ilə, həmçinin knip alətini — o, bütün layihə üzrə exports və imports-ları təhlil edərək istifadə olunmayan faylları, funksiyaları və asılılıqları tapır. Böyük monorepozitoriyalar üçün knip ən dolğun mənzərəni göstərir.
Buraxılışdan əvvəl silmək daha yaxşıdır, lakin son anda yox. Ölü kodun silinməsi ayrıca sprində planlaşdırılan texniki işdir. Buraxılışdan dərhal əvvəl silmə qeyri-sabitlik gətirə bilər, əgər kod göründüyü qədər ölü deyilsə.
Bəli, müasir kompilyatorlar və minifikatorlar (ProGuard, R8, Terser, Closure Compiler) Dead Code Elimination səviyyəsində əlçatmaz kodu silir. Lakin bu, mənbə kodlarının təmizlənməsi zərurətini aradan qaldırmır: kompilyator kodu binar fayldan silir, lakin repozitoriyadan yox — proqramçılar oxuyarkən yenə də ona rast gələcəklər.
Nəticə
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun