Geliştirmede Junk — Nedir, Çöp Kod Neden Zararlıdır ve Nasıl Kaldırılır

Junk Kodu Nedir?

Junk (çöp kod), bir projede bulunan ancak işlevsel değer sağlamayan kod, yapılandırma ve bağımlılıklar için kullanılan kolektif bir terimdir. Junk mutlaka bozuk veya kullanılmamış değildir — sorun, varlığının yeterli gerekçe olmadan proje metriklerini kötüleştirmesidir.

Junk dört kategoriye ayrılır. Birincisi — gereksiz bağımlılıklar: standart araçlarla uygulanabilecek tek bir özellik için eklenen kütüphaneler. İkincisi — ölü ağırlık: yorumlanmış bloklar, biletsiz TODO‑lar, boş metotlar ve stub sınıflar. Üçüncüsü — yinelenen çözümler: aynı işi yapan iki kütüphane (örneğin, aynı projede Gson ve Kotlin Serialization). Dördüncüsü — aşırı mühendislik: kullanılmayan ancak “yedek olsun” diye bakımı yapılan mimari katmanlar.

Stripe Engineering Productivity (2025) araştırmasına göre, tipik bir projeden yüzde 10 junk‑ın kaldırılması, tam derleme süresini ortalama yüzde 22 azaltır. Nedeni: her ek bağımlılık derleme grafiğini artırır, her boş soyutlama anlaşılması için zaman gerektirir, her yorumlanmış blok dikkati dağıtır.

Junk ile mücadeledeki ana zorluk, ani sonuçların olmamasıdır. Junk kodu olan bir proje derlenir ve çalışır. Sorunlar yavaş yavaş birikir: derleme yavaşlar, geçişli bağımlılıkların sayısı artar ve bir yıl sonra yeni bir özellik eklemek gereken sürenin iki katını alır.

Junk Bağımlılıklar ve Nasıl Belirlenir

Junk bağımlılıklar, bir projeye eklenen ancak kodda doğrudan kullanılmayan veya yalnızca standart API‑lerle uygulanması daha basit olan tek bir özellik için kullanılan kütüphane ve paketlerdir.

Tipik örnekler: proje zaten Kotlin Serialization kullanırken JSON işleme kütüphanesi (iki ayrıştırıcı junk‑tır); Kotlin eklentisi isNullOrBlank ile değiştirilebilecek tek bir StringUtils.isEmpty çağrısı için Apache Commons Lang kütüphanesi; on modülden birinde kullanılan ve diğerlerinin bağımlılıkları manuel olarak constructor üzerinden aldığı bir DI kütüphanesi.

Her ek bağımlılık, ikili dosyadaki yalnızca ekstra kod değildir. Güvenlik açıkları için saldırı yüzeyini artırır: GitHub Advisory Database (2025)’e göre, mobil projelerdeki kritik CVE‑lerin yüzde 40‑ı, geliştiricilerin kontrol edemediği geçişli bağımlılıklardan gelir. Bağımlılıklar ne kadar azsa, saldırı yüzeyi o kadar küçüktür.

Android Proje Bağımlılık Analizi

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

iOS için, tam bağımlılık ağacını gösteren swift package show-dependencies komutunu kullanın. Xcode Build Timeline aracı, her kütüphanenin derlemeye ne kadar süre eklediğini gösterir. Bir kütüphane derleme süresinin yüzde 30‑unu alıyor ancak tek bir ekranda kullanılıyorsa, kaldırma veya değiştirme adayıdır.

Node.js (React Native) için, package.json’da kullanılmayan bağımlılıkları bulan depcheck ve ayrıca eski sürümleri gösteren npm-check kullanın. Bir kural getirin: her yeni bağımlılık, “neden standart araçlar kullanılamıyor” gerekçesiyle kod incelemesinden geçmelidir.

Ölü Import‑lar ve Yorumlanmış Kod

Ölü import‑lar en yaygın junk türüdür. Çalışma zamanını etkilemezler ancak derleme süresini artırırlar: derleyici, kullanılmayanlar dahil her import‑u işler. Büyük projelerde, kullanılmayan import‑ların kaldırılması derleme süresini yüzde 5–10 azaltır.

Modern IDE‑ler, kullanılmayan import‑ları otomatik olarak gri renkte vurgular. Dosya kaydetmede otomatik temizlik ayarlayın: IntelliJ IDEA’da — Optimize Imports on the fly, Xcode’da — Editor > Remove Unused Imports. CI’a bir kontrol ekleyin: lint’leyici, kullanılmayan import‑ları olan commit‑leri engellemelidir.

Yorumlanmış kod başka bir junk türüdür. Geliştiriciler, yeniden düzenleme sırasında işlevselliği “kaybetmemek” için blokları yorum satırına alır. Ancak git, değişikliklerin tam geçmişini saklar: kaldırılan herhangi bir kod, tek bir git revert veya git log -S komutuyla geri yüklenebilir. Master‑daki yorumlanmış kod ekibe saygısızlıktır: her geliştirici, “bu neden yorumlanmış ve ne zaman yorumdan çıkarılmalı?” sorusuna zihinsel enerji harcar.

Kural: depoda yorumlanmış kod yoktur. Kod gerekli değilse kalıcı olarak silin. Kod gerekli ancak geçici olarak devre dışıysa, bir ticket ve son kullanma tarihi ile özellik değiştirici (feature toggle) kullanın. // TODO: remove after migration gibi yorumlar — son teslim tarihi olmadan bırakmayın. Bir tarih belirleyin ve takvimle kendinize hatırlatın.

Gereksiz Soyutlamalar ve Aşırı Mühendislik

Aşırı mühendislik, mevcut sorunları çözmeyen ancak bakım gerektiren mimari katmanlar oluşturmaktır. Bu, en zor junk türlerinden biridir çünkü biçimsel olarak kod “doğrudur”: SOLID’i takip eder, testlerle kapsanır ve mimariye uygundur. Sorun, gerekli olmamasıdır.

Klasik bir örnek, yalnızca bir havuzu çağıran tek bir invoke metodu olan soyut UseCase sınıfıdır. UseCase herhangi bir mantık (önbellekleme, yeniden deneme, dönüştürme) eklemiyor ve yalnızca çağrıyı iletiyorsa, gereksiz bir varlıktır. Projede gezinmeyi artırır: geliştirici UseCase’i açar, invoke → havuzu görür ve kapatır. Zaman kaybı, sıfır fayda.

Başka bir örnek aşırı parametrelendirmedir. Tek bir yerde kullanılan altı tip parametresine sahip genel bir arayüz. Her tip parametresi bilişsel yüktür: kodu okurken, yalnızca ikisi gerçekten kullanılmasına rağmen altı tipi akılda tutmak gerekir. Bir soyutlama yeniden kullanılmıyorsa gereksizdir.

Kesme kriteri: bir soyutlama üç farklı bağlamda yeniden kullanılmıyorsa, kaldırın. Bir soyutlama, varsayımsal gelecek senaryolarını tahmin ettiğinde değil, gerçekten bir tekrarlama sorununu çözdüğünde haklı çıkar. YAGNI (You Ain’t Gonna Need It), aşırı mühendisliği önlemenin en iyi ilkesidir.

Junk Denetim Araçları

Junk denetimi, statik analiz, bağımlılık analizi ve manuel incelemenin bir kombinasyonunu gerektirir. Gereksiz soyutlamaların tespitini tamamen otomatikleştirmek imkansızdır, ancak teknik junk (ölü import‑lar, kullanılmayan kütüphaneler, yorumlanmış kod) araçlarla bulunabilir.

Tam bir denetim için, sprint başına bir kez buildHealth (Android) veya depcheck (Node.js) çalıştırın. CI’da, sprintler boyunca bağımlılık sayısı eğilimini gösteren bir pano oluşturun. Sayı artıyor ancak işlevsellik orantılı olarak artmıyorsa, ekip junk biriktiriyordur.

Yinelenen sınıflara dikkat edin — iki kütüphane aynı sınıfı içerdiğinde oluşan bir hata. Bu yalnızca junk değil, aynı zamanda doğrudan derleme çakışmaları kaynağıdır. Gradle’da bu çakışmalar force veya exclude ile çözülür, ancak her çözüm, kütüphanelerden birinin gereksiz olduğunun bir işaretidir.

Düzenli Proje Temizleme Süreci

Junk temizliği tek seferlik bir eylem değil, düzenli bir süreçtir. Bir prosedür olmadan, junk iki ila üç sprint içinde geri döner. En iyi uygulama, her sprint kapasitesinin yüzde 10–15’ini teknik temizliğe (junk denetimi dahil) ayırmaktır.

Süreç dört adımdan oluşur. Birincisi — teşhis: araçları çalıştırın, rapor alın, önceliklendirin. Yüksek öncelik: bilinen CVE‑leri olan bağımlılıklar ve yinelenen kütüphaneler. Orta öncelik: ölü import‑lar ve yorumlanmış kod. Düşük öncelik: gereksiz soyutlamalar (manuel analiz gerektirir).

İkincisi — temizlik: ölü bağımlılıkları kaldırın, yinelenen kütüphaneleri bir taneyle değiştirin, yorumlanmış kodu silin. Her değişiklik, net bir mesajla ayrı bir commit olmalıdır: “remove unused dependency: gson (replaced by kotlinx.serialization)”, “delete commented code in LoginViewModel.”

Üçüncüsü — doğrulama: projeyi derleyin, testleri çalıştırın, arayüzü kontrol edin. Bir bağımlılığı kaldırdıktan sonra testler geçerse, bağımlılık gerçekten gereksizdi. Testler başarısız olursa, statik analizörün algılamadığı gizli bir referans vardır.

Dördüncüsü — önleme: kod inceleme kontrol listesini güncelleyin, Tanım’a “gerekçesiz yeni bağımlılık olmaz” kuralı ekleyin, CI’da otomatik kontroller kurun. Önleme, junk‑ın yeniden birikmesini önlemenin tek yoludur.