Geliştirmede ölü kod ve zombi kod: nedir, nedenleri ve arama

Ölü kod nedir?

Ölü kod (dead code), programa dahil edilen ancak hiçbir kullanım senaryosunda asla çalıştırılmayan kaynak koddur. Derleyici veya yorumlayıcı onu işler, ancak çalışma zamanında kontrol bu bölümlere asla ulaşmaz.

Ölü kodun klasik örnekleri: değer atanan ancak asla okunmayan değişkenler; hiçbir yerde çağrılmayan işlevler veya yöntemler; asla doğru olmayan koşul dalları (if(false)); gövdesi bir kez bile çalıştırılmayan döngüler.

SonarQube State of Code Quality (2025) raporuna göre, ticari Java projelerindeki tüm uyarıların yaklaşık yüzde 15'i kullanılmayan private yöntem ve alanlarla ilgilidir. JavaScript projelerinde, dilin dinamik yapısı ve üçüncü taraf kütüphanelerin bolluğu nedeniyle kullanılmayan kod oranı yüzde 30'a ulaşabilir.

Projenizi düzenli olarak ölü kod açısından kontrol edin — özellikle büyük yeniden düzenlemeler ve özellik kaldırma işlemlerinden sonra. Bugün unutulmuş bir import veya kullanılmayan bir işlev, yarın ekip üyelerini yanıltan zombi koda dönüşebilir.

Ölü kod ve zombi kod arasındaki farklar

Zombi kod (zombie code), tarihsel bağlamıyla ayrılan özel bir ölü kod durumudur. Zombi kod bir zamanlar çalışıyordu, ancak sistemdeki değişikliklerden sonra erişilemez hale geldi, yine de silinmedi, «ihtimale karşı» bırakıldı.

Ölü kod ve zombi kod arasındaki fark — kökendedir. Ölü kod hatalı yazılmış olabilir (hiç çalışmamıştır), zombi kod ise yeniden düzenlemeden sonra güncelliğini kaybetmiş eski canlı koddur. Örneğin, yenisiyle değiştirilen eski iş mantığına göre indirim hesaplama işlevi, ancak eski yöntem silinmedi — geri dönme ihtimaline karşı.

Zombi kodun ana tehlikesi — çalışan işlevsellik yanılsamasıdır. Yeni bir geliştirici bir işlev görür, belgelerini okur, bir yerde çağrıldığını varsayar — ve bir yapıtı incelemekle zaman kaybeder. Doğrudan çağırmaya çalıştığında, silinmiş varlıklara veya eski API'lere bağımlı olduğu ortaya çıkabilir.

Zombi kodu git geçmişi üzerinden takip edin: bir işlev iki yıldır değiştirilmemişse ve kullanılmıyorsa — zombidir. Tereddüt etmeden kaldırın, çünkü git geçmişi tutar ve gerektiğinde kod her zaman geri yüklenebilir.

Ölü kodun ortaya çıkma nedenleri

Birinci ve en yaygın neden — eksik yeniden düzenleme ile yinelemeli geliştirme. Ekip, eskisinin yerine yeni işlevsellik ekler, ancak değiştirilen modülleri kaldırmaz. Sprintler bu «kuyrukları» biriktirir ve bir yıl sonra proje ölü kod tabakasıyla kaplanır.

İkinci neden — A/B testi ve özellik toggle. Yeni bir özelliği etkinleştirme koşulları zamanla sabitlenebilir (örneğin, her zaman true), ancak alternatif mantığa sahip else dalı kodda kalır. Geliştiriciler, toggle geri çevrilirse yanlışlıkla sistemi kırmaktan korkarak onu silmekten çekinirler.

Üçüncü neden — otomatik oluşturma ve kopyala-yapıştır. Kod oluşturucular (IDE, şablon motorları), geliştiricinin doldurmadığı veya kullanmadığı yöntemlerle şablonlar oluşturur. Başka bir projeden kopyalanan kod genellikle yeni bağlamla ilgisi olmayan tüm blokları içerir.

Dördüncü neden — silme korkusu. Büyük projelerde geliştiriciler, kodun gerçekten hiçbir yerde kullanılmadığından emin olmadıkları için kodu silmekten korkarlar. Bu korku, zayıf test sistemiyle daha da kötüleşir: otomatik kontrol yoksa, silme işlemi yalnızca üretimde keşfedilen hatalara yol açabilir.

Ölü kodun tehlikeleri

Ölü kod, proje kalitesinin dört yönünü doğrudan etkiler: derleme performansı, yapıt boyutu, ekibin bilişsel yükü ve yeniden düzenlemenin güvenilirliği.

Derleme süresinde artış: derleyici kullanılmayan dosyaları işler, bağımlılıkları analiz eder ve asla çalışmayacak parçalar için bayt kodu veya makine kodu üretir. Büyük projelerde bu, her derlemeye dakikalar ekler. Yorumlanan dillerde (JavaScript, Python) modül yükleme süresi ve bellek tüketimi artar.

Değişiklik sırasında hata riski: bir geliştirici kodu değiştirir ve işlevin yalnızca ölü bir dalda kullanıldığından şüphelenmez. Yeniden düzenlemeden sonra ölü kod derlenmeyi durdurur veya hatalar üretir — ekip, uygulamanın çalışmasını etkilemeyen bir sorunu teşhis etmekle zaman kaybeder.

Bilişsel yük — en pahalı faktör. Kullanılmayan her işlev, kod okunurken dikkat gerektirir. Geliştirici, bu kodun neden var olduğunu ve nerede çağrıldığını anlamak için zihinsel enerji harcar. Developer Productivity Lab (2025) araştırması şunu gösterdi: ölü kodun yüzde 20'sini kaldırmak, işe alıştırma süresini ortalama yüzde 18 azaltır.

Ölü kodu keşfettiğinizde hemen kaldırın. Her günlük gecikme, ekipten birinin daha dün kaldırılması gereken bir yapıtı incelemekle saatler kaybetme olasılığını artırır.

Ölü kod arama araçları

Ölü kod araması iki ana yöntemle yapılır: statik analiz (programı çalıştırmadan) ve dinamik analiz (çalışma zamanında kapsama profil oluşturma). Her yaklaşım farklı ölü kod türleri için etkilidir.

Statik analizörler tüm popüler programlama dillerini destekler. Java ve Kotlin için — SonarQube, IntelliJ IDEA Inspections, SpotBugs. JavaScript ve TypeScript için — no-unused-vars ve no-unused-modules kurallarıyla ESLint. Swift için — unused_declaration kuralıyla SwiftLint. Python için — unused-import seçeneğiyle pylint ve derin arama için vulture.

ProGuard aracılığıyla Kotlin'de arama örneği

// build.gradle.kts - Android için ProGuard yapılandırması
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro - yalnızca gerekli sınıfları tut
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard yalnızca kullanılmayan sınıfları ve yöntemleri kaldırmakla kalmaz, aynı zamanda sürüm derlemesinde adları küçültür. ProGuard etkinleştirilmiş derleme, hangi sınıf ve yöntemlerin kullanılmadığını otomatik olarak gösterir — usage.txt raporunda kaldırılan tüm kod listelenir.

Test kapsaması yoluyla dinamik analiz

Kod kapsama araçları (Java için JaCoCo, Swift için XCTest coverage, JavaScript için Istanbul), testler sırasında hangi satırların ve dalların çalıştırıldığını gösterir. Sıfır kapsamalı yöntemler — ölü kod adayları. Ancak kapsama eksikliği, kodun üretimde çağrılmadığını garanti etmez — tam kesinlik için statik ve dinamik analiz kombinasyonunu kullanın.

CI boru hattınızı, kullanılmayan bildirim eşiği aşıldığında derlemenin başarısız olması için yapılandırın. «Kullanılmayan private kod oranı %3'ü geçmez» kuralıyla SonarQube Quality Gate, geliştirme süreci düzeyinde ölü kod birikimini önler.

Ölü kod güvenle nasıl kaldırılır

Ölü kod kaldırma süreci dört adımdan oluşur: bul, kontrol et, kaldır, tekrar kontrol et. Herhangi bir adımı atlamak gerileme riskini artırır.

İlk adım — statik analizör aracılığıyla aday arama. Kullanılmayan bildirimlerin raporunu alın: işlevler, sınıflar, değişkenler, importlar. Yanlış pozitifleri filtreleyin — analizörler bazen yansıma, dinamik sınıf yükleme veya serileştirme yoluyla gizli çağrılarda hata yapar.

İkinci adım — git blame ve değişiklik geçmişi üzerinden kontrol. Kodun ne zaman ve neden yazıldığını görün. Kod, özellik toggle ile devre dışı bırakılan bir özelliğin parçasıysa — toggle'ın sabit olduğundan ve tekrar açılmayacağından emin olun. Silmekte tereddüt ettiğiniz kodu yorum haline getirin ve bir ay sonra yeniden kontrol için TODO bilet bırakın.

Üçüncü adım — testlerin tam takımını çalıştıran ayrı bir daldan kaldırma. Testler geçerse — gerileme olasılığı düşüktür. Testler başarısız olursa — kod hala kullanılıyor demektir ve hangi senaryoda olduğunu anlamak gerekir.

// before - aynı dosyada ölü kod ve zombi kod
int calculateV1(int price) { // hiçbir yerde çağrılmıyor
    int tax = price * 0.18;
    return price + tax;
}

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

// after - ölü kod kaldırıldı, zombi kod temizlendi
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

Dördüncü adım — değişikliklerin kod incelemesi. İnceleyici, kodun gerçekten ölü olduğunu onaylamalıdır. İnceleyici emin değilse — kodda yorum bırakın ve tam analize kadar kaldırmayı erteleyin. Dal birleştirildikten sonra — git deposunda zombi kodun çoğalmaması için dalı silin.

Kural uygulayın: hiçbir çekme isteği yeni ölü kod içermemelidir. Kullanılmayan değişkenler veya importlar olduğunda commit'i engelleyen bir linter'ı ön-commit kancalarına ekleyin. Önleme her zaman temizlikten daha ucuzdur.