Programlamada kötü kod: nedir, belirtileri ve nasıl daha temiz yazılır

Programlamada kötü kod nedir

Kötü kod, minimum kalite standartlarını karşılamayan kodun öznel ancak genel kabul görmüş bir tanımıdır. Robert Martin, Clean Code (2008) kitabında kötü kodu, “ne yaptığını anlamayı engelleyen kod” olarak tanımlar. Kötü kod sözdizimsel olarak doğru ve hatta çalışır durumda olabilir, ancak bakımı ekip için bir kabusa dönüşür.

Kötü kod terimi özellikle Rusça konuşan toplulukta yaygındır. İngilizcede daha resmi terimler kullanılır: spaghetti code, dirty code, technical debt code. Ancak “kötü kod” ifadesinin duygusal rengi, geliştiricilerin bu tür koda karşı tutumunu — rahatsızlık, tiksinme ve mesleki hakaret karışımı — daha doğru bir şekilde aktarır.

McKinsey araştırmasına (2023) göre, yüksek düzeyde teknik borcu olan şirketler — ve kötü kod bunun ana bileşenidir — yeni özellikler geliştirmek için %20–40 daha fazla kaynak harcar. Kod kalitesi iş metriklerini doğrudan etkiler ve bu bir metafor değil, doğrulanmış bir gerçektir.

Kötü kod ile normal kod arasındaki sınır

Nesnel metrikler mevcut değildir, ancak pratik kriterler vardır: bir geliştirici 20 satırlık bir işlevi anlamak için 5 dakikadan fazla zaman harcıyorsa — bu kötü koddur. Bir satırı değiştirmek ilgisiz üç modülü bozuyorsa — bu kötü koddur. Kod, tamamen yeniden yazılmadan testlerle kapsanamıyorsa — bu kötü koddur.

Kötü kodun başlıca belirtileri

Kopyala-yapıştır programlama, en belirgin ve kolayca tespit edilebilir belirtilerden biridir. Aynı kod bloğu minimum değişiklikle birden çok yerde tekrarlanıyorsa, bu sadece kötü kod değil — gelecekteki hataların kaynağıdır. Bir yerde düzeltip diğerinde atlamak tipik bir durumdur.

Anlamsız değişken isimleri bir klasiktir. `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` gibi isimlere sahip değişkenler amaçları hakkında hiçbir bilgi taşımaz. Kod okuyucusu, değişkende ne olduğunu anlamak için tüm işlevi analiz etmek zorundadır. Robert Martin buna “isimde yalan” der — isim bilgi vaat eder ancak sunmaz.

Derin iç içe geçme — koşullar, döngüler ve hata işleme, 5+ girinti seviyesine sahip bir yapı oluşturduğunda. Bu tür kodu yatay kaydırma veya tüm seviyeleri zihinsel olarak takip etme olmadan okumak imkansızdır. Bu, hatalara giden doğrudan bir yoldur: mantıksal operatörler kolayca karıştırılır ve kapanış parantezleri gözden kaçar.

Gizli belirtiler

Ölü kod (dead code) — hiçbir yerde kullanılmayan işlevler, değişkenler, sınıflar. Bu, kod hacmini artırır, geliştiricinin dikkatini dağıtır ve sistemin yetenekleri hakkında yanlış bir izlenim yaratır. Sihirli sayılar — bağlamı olmayan sayılar. God sınıfları — tek sorumluluk ilkesini (SOLID: S) ihlal ederek her şeyi aynı anda yapan sınıflar.

Kötü kod neden ortaya çıkar

Zaman eksikliği en yaygın nedendir. Teslim tarihleri yaklaştığında, geliştiriciler hız için kaliteden ödün verir. Taktik olarak bu haklı görülebilir, ancak stratejik olarak — teknik borç biriktirmektir. Sorun şu ki, “geçici” kötü kod düzeltilmek üzere nadiren tekrar gözden geçirilir.

Kod incelemesinin olmaması ikinci en önemli nedendir. Kod, akran incelemesi olmadan tek başına yazıldığında, kötü kalıplar kök salar ve çoğalır. Kod incelemesi sadece kalite kontrolü değil, aynı zamanda ekip içinde bilgi aktarımıdır. İncelemesi olmayan projeler kaçınılmaz olarak kötü koda dönüşür.

Geliştiricinin düşük niteliği veya mentorluk eksikliği. Denetimsiz bırakılan genç geliştiriciler doğal olarak kötü kod yazar — bu öğrenme sürecinin bir parçasıdır. Sorun, bu kodun inceleme ve yeniden düzenleme olmadan üretime geçmesiyle ortaya çıkar.

Kültürel faktörler

“Çalışıyor,” mottosu olan takımlarda kötü kod gelişir. Kodlama standartlarının, test gereksinimlerinin ve inceleme süreçlerinin yokluğu, kod kalitesinin kimsenin umurunda olmadığı bir ortam yaratır. Bu tür projeler hızla “legacy” haline gelir — herkesin dokunmaktan korktuğu kod.

Kötü kodun proje için sonuçları

Kötü kodun ana sonucu, geliştirmenin yavaşlamasıdır. Kötü kodun paradoksu, ilk sürümü hızlıca yazmaya izin vermesi, ancak sonraki her düzeltmenin giderek daha fazla zaman almasıdır. Kod kalitesine karşı geliştirme hızının grafiği üsseldir — belirli bir eşikten sonra yeni özellikler eklemek pratikte imkansız hale gelir.

Personel devri dolaylı ancak ciddi bir sonuçtur. Geliştiriciler, özellikle deneyimli olanlar, kötü kodla çalışmak istemez. Stack Overflow Geliştirici Anketi 2024’e göre, geliştiricilerin %47’si bir iş yeri seçerken kod tabanı kalitesini temel faktörlerden biri olarak belirtmektedir. Kötü koda sahip projeler en iyi çalışanlarını kaybeder.

Güvenlik kötü kodun bir başka kurbanıdır. Kötü yazılmış kod daha fazla güvenlik açığı içerir: işlenmeyen istisnalar, SQL enjeksiyonları, XSS, bellek sızıntıları. Birim testleri ve kod incelemesi ile kaliteli kod, bu sorunların çoğunu üretimden önce yakalar.

Bir metrik olarak teknik borç

SonarQube ve benzeri araçlar, teknik borcu kişi-saat veya gün olarak tahmin edebilir. Örneğin, kopyala-yapıştırla ilgili 500 uyarı, sihirli sayılarla ilgili 200 ve derin iç içe geçmeyle ilgili 50 uyarı, 30 günlük teknik borç tahmini verir. Bu rakamlar, yeniden düzenlemeyi haklı çıkarmak için yönetime gösterilebilir ve gösterilmelidir.

Kötü kod yerine nasıl temiz kod yazılır

DRY (Don’t Repeat Yourself) ilkesi uygulanması gereken ilk şeydir. Her mantık parçası tek bir yerde bulunmalıdır. Kopyala-yapıştır yerine — tekrarlanan kodu ayrı bir işleve, sınıfa veya modüle çıkarın. Sihirli sayılar yerine — adlandırılmış sabitler. Uzun işlevler yerine — birkaç küçük işlev.

KISS (Keep It Simple, Stupid) ilkesi aşırı karmaşıklığa karşı korur. Bir görev 10 satırda çözülebiliyorsa — 50 yazmayın. Bir döngü bir akıştan daha basitse — döngü kullanın. Sıradan bir işlev bir dekoratörden daha netse — işlev yazın. Basitlik, bakımı yapılabilir kodun temel kalitesidir.

İzci kuralı — “kodu bulduğundan daha iyi bırak.” Her düzenlemede küçük iyileştirmeler bile zamanla kötü kodu iyi koda dönüştürür. Bir değişkeni yeniden adlandırın, büyük bir işlevi bölün, bir test ekleyin — her iyileştirme önemlidir.

// kötü kod — kopyala-yapıştır, sihirli sayılar, zayıf isimler
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// temiz kod — net isimler, DRY, sabitler
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Yeniden düzenleme örnekleri

Python’da tipik bir örneği ele alalım. İşlev siparişleri işler ancak bunu kötü yapar: 80 satır, derin iç içe geçme, sihirli sayılar, tekrar. Yeniden düzenlemeden sonra kod okunabilir, test edilebilir ve bakımı yapılabilir hale gelir.

# kötü kod — tek bir işlev her şeyi yapar
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# temiz kod — çıkarılmış işlevler ve sabitler
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

İşlevler için üç satır kuralı

İyi bir işlev tek bir şey yapar ve onu iyi yapar. Bir işlev üç farklı şey yapıyorsa — bölün. Bir işlev 20 satırdan fazlaysa — muhtemelen bölünebilir. Bir işlevde ikiden fazla girinti seviyesi varsa — yeniden düzenleme gerektirir.

Kod inceleme araçları

Statik kod analizörleri, kötü koda karşı ilk savunma hattıdır. ESLint (JavaScript), Pylint (Python), SonarQube (çok dilli), Checkstyle (Java), kopyala-yapıştır, sihirli sayılar, boş catch blokları, aşırı uzun işlevler ve yüzlerce diğer anti-örüntüyü otomatik olarak tespit eder.

Kod stili ve biçimlendiriciler ikinci koruma seviyesidir. Prettier, Black, gofmt kodu otomatik olarak biçimlendirerek boşluk, girinti ve parantez sorunlarını ortadan kaldırır. Takımda tutarlı bir stil, kodu kimin yazdığına bakılmaksızın okunabilir kılar. Biçimlendirme tartışmaları otomatikleştirilmelidir.

Kod incelemesi üçüncü ve en önemli seviyedir. Hiçbir analizör, çözüm mimarisinin yanlış olduğunu veya geliştiricinin yanlış yaklaşımı seçtiğini fark eden bir insanın yerini alamaz. Etkili inceleme zaman alır, ancak kötü kod miktarını önemli ölçüde azaltarak karşılığını verir.

• ESLint — karmaşıklık, max-lines, max-nested-callbacks kurallarıyla JavaScript ve TypeScript için
• Pylint — kod metrikleri ve kalite puanıyla (-10’dan 10’a) Python için
• SonarQube — teknik borcu zaman içinde izlemek için
• CodeClimate — her dosyanın bakım yapılabilirlik indeksini değerlendirmek için
• Better Code Hub — temiz kodun 10 ilkesine uygunluğu kontrol etmek için