Kod Kalitesi Nasıl Ölçülür? Tek Tek Hatalardan Ekip ve Organizasyon Trendlerine

Kısa özet: Kod kalitesi yalnızca bug sayısı, test coverage yüzdesi veya linter uyarısı ile ölçülemez. Sağlıklı bir ölçüm sistemi en az dört seviyeyi birlikte izlemelidir: Pull request sırasında eklenen yeni kalite sorunları, Repository’de biriken teknik borç, Takım ve organizasyon genelindeki kalite trendi, Production’a kaçan problemlerin gerçek kullanıcı etkisi. GitHub Code Quality artık reliability ve maintainability bulgularını repository seviyesinde sınıflandırıyor; 19 Ağustos 2026’da eklenen organizasyon trend görünümüyle açık bulguların 7, 14 veya 30 günlük değişimini ve hangi repository’lerin iyileştiğini ya da gerilediğini gösterebiliyor. Ancak sağlıklı mühendislik yönetimi için yalnızca “kaç uyarımız var?” sorusu yeterli değildir. Asıl soru: Yeni teknik borç üretiyor muyuz, mevcut borcu azaltıyor muyuz ve kod kalitesindeki değişiklik production sonuçlarına nasıl yansıyor? olmalıdır.

Kısa doğrudan cevap

Kod kalitesini ölçmek için tek bir skor yerine şu metrikleri birlikte kullanın:

• Yeni PR bulguları
• Severity dağılımı
• Reliability / Maintainability skorları
• Coverage ve coverage delta
• Açık bulgu trendi (7, 14, 30 gün)
• Yeni borç / çözülen borç oranı (Remediation Ratio)
• Quality gate ihlalleri ve rule bypass oranı
• Production'a kaçan hatalar (Escaped defects)

Repository düzeyindeki teknik metrikleri, ekip düzeyindeki trendler ve production sonuçlarıyla birleştirin. Örneğin %82 coverage tek başına iyi kalite anlamına gelmez. Aynı repository %82 coverage + artan Error seviyesi bulgular + yüksek production incident üretiyorsa kalite problemi devam ediyor olabilir.

Kod kalitesi tam olarak nedir?

Kod kalitesi iki ana teknik boyutta değerlendirilir:

• Reliability: Kodun amaçlanan işlevi doğru, öngörülebilir ve tutarlı biçimde gerçekleştirmesi (correctness, error handling, concurrency, performance).
• Maintainability: Kodun gelecekte anlaşılması, değiştirilmesi ve genişletilmesinin ne kadar kolay olduğu (dead code, complexity, readability, separation of concerns).

Bu ayrım önemlidir çünkü “Kod çalışıyor” ile “Kod sağlıklı” aynı şey değildir. Bir fonksiyon bugün doğru sonuç verebilir fakat o kadar karmaşık olabilir ki altı ay sonra değiştirilmesi ciddi regression riski yaratabilir.

Neden bug sayısı tek başına iyi bir kalite metriği değildir?

Açık bulunan hata sayısı tek başına kalite göstergesi olamaz. Güçlü test, CodeQL ve agresif statik analiz kullanan bir ekip daha fazla bug keşfedip kapatabilir; zayıf test altyapısına sahip ekip ise az bug "bulup" sorunları production'da kullanıcıya yaşatabilir. Dolayısıyla bulunan hata sayısı ile gerçek kalite aynı şey değildir. Bazen daha iyi kalite sistemi daha fazla problemi görünür hale getirir.

Kod kalitesi ölçümünde en önemli ayrım: stok ve akış

• Stok (Anlık Durum): Şu anda ne kadar açık problemimiz var? (Örn. 420 açık finding).
• Akış (Trend): Durum hangi yönde değişiyor? (Örn. Son 30 gün: +110 yeni, -170 çözülen = -60 net).

İkinci bilgi genellikle çok daha değerlidir. Büyük ve eski bir repository'nin 500 açık finding bulundurması doğal olabilir. Asıl önemli soru: Bu sayı sürekli büyüyor mu, yoksa küçülüyor mu?

GitHub organizasyon seviyesinde bunu nasıl ölçüyor?

GitHub 19 Ağustos 2026’da Code Quality organizasyon dashboard’una Trends görünümünü ekledi. Bu görünüm 7, 14 ve 30 günlük periyotlarda açık bulguların nasıl değiştiğini, net değişimi, en çok iyileşen ve desteğe ihtiyacı olan repository'leri gösteriyor. Bu özellik GitHub Team ve Enterprise Cloud kullanıcıları için aktiftir.

GitHub health score nasıl çalışıyor?

| Health Score | Genel Sağlık Seviyesi | İnceleme / Öncelik |

Severity seviyeleri ise `Error`, `Warning` ve `Note` olarak ayrılır.

Mühendislik yönetimi için kritik 11 metrik

Metrik 1 — Yeni PR başına eklenen kalite problemi

Yeni kod tabanına ne kadar yeni debt ekleniyor? (Yeni finding / PR veya Yeni finding / 1.000 değişen satır). Amaç geliştiricileri sıralamak değil, teknik borç üretim hızını ölçmektir.

Metrik 2 — Severity dağılımı

100 adet Note ile 1 adet Error aynı etkiye sahip değildir. Bulguları Error (yüksek), Warning (orta) ve Note (düşük) olarak ayırın.

Metrik 3 — Açık finding trendi

Açık bulguların 7/14/30 günlük değişimi. Yönün eksiye (iyileşmeye) gitmesi hedeflenmelidir.

Metrik 4 — Yeni borç ile çözülen borç oranı (Remediation Ratio)

`Remediation Ratio = Çözülen finding / Yeni finding`. Oranın > 1,0 olması teknik borcun küçüldüğünü gösterir.

Metrik 5 — Pull request öncesi çözüm oranı

`Pre-Merge Remediation Rate = Merge öncesi çözülen finding / PR'da bulunan finding`. GitHub kendi mühendislik organizasyonunda bu oranın %67,3 olduğunu raporlamıştır.

Metrik 6 — Code coverage ve coverage delta

Mutlak coverage yüzdesi yerine PR branch'i ile default branch arasındaki `coverage delta` (örn. +6 percentage points) daha güçlü bir sinyaldir. GitHub coverage düşüşlerini ruleset ile engelleyebilmektedir.

Metrik 7 — Quality gate başarısızlıkları

Hangi kuralların en sık ihlal edildiğini ve tekrar eden design smell'leri tespit etmek için izlenir.

Metrik 8 — Ruleset bypass oranı

Organization-level Rule Insights ile belirlenen kalite kurallarının ne sıklıkla bypass edildiği takip edilir.

Metrik 9 — Finding yaşı (Finding age)

Açık bulguların ortalama yaşı (0–30 gün, 31–90 gün, 180+ gün). Kronik teknik borcu ortaya çıkarır.

Metrik 10 — Teknik borcun hangi modüllerde yoğunlaştığı

Teknik borcun (örneğin %60'ının) hangi spesifik modülde (örn. Billing, Auth) toplandığını gösteren heatmap analizi.

Metrik 11 — Production’a kaçan hata (Escaped defects)

Pre-production metriklerini doğrulayan gerçek dünya metriği: Release kaynaklı production bug sayısı ve incident oranı.

Code Quality ile DORA metrikleri ilişkisi

DORA software delivery ve operasyonel performansı (deployment frequency, lead time, change failure rate, recovery time) ölçer. Code Quality ise kaynak kod sağlığını (reliability, maintainability, findings, coverage) ölçer. Sağlıklı bir organizasyonda her iki metrik kümesi birlikte değerlendirilmelidir.

Kod kalitesi için 4 katmanlı ölçüm modeli

Örnek dashboard

| Katman | Metrik | İdeal Yön / Hedef |

Bu tablo InoviqLab ölçüm modelidir.

Kod kalitesini ölçerken yapılan 7 hata

1. Sadece coverage'a bakmak.

2. Sadece toplam finding sayısına bakmak.

3. Developer'ları finding sayısıyla sıralamak.

4. Legacy ve yeni code'u aynı değerlendirmek.

5. False positive oranını takip etmemek.

6. Production sonuçlarını görmezden gelmek.

7. Her repository'ye aynı kalite hedefini koymak.

InoviqLab teknik değerlendirmesi

• Direction > Snapshot: "Kaç hatamız var?" değil, "Hata üretim hızımız mı yüksek, çözüm hızımız mı?" sorusu önemlidir.
• Kalite metriği cezalandırma aracı olmamalıdır: Geliştiricileri skorlamak yerine sistemleri ve repository'leri geliştirmek için kullanılmalıdır.
• New-code policy: Legacy debt bir gecede sıfırlanamaz; öncelik "bugünden itibaren yeni Error eklememek" olmalıdır.
• AI çağında kalite trendleri: AI agent'lar kod üretim miktarını artırdığı için kalite kontrolünün aynı hızda ölçeklenmesi ve technical debt trendinin izlenmesi kritik hale gelmiştir.

Sonuç

Kod kalitesi tek bir sayı değildir. 23 Ağustos 2026 itibarıyla GitHub Code Quality reliability, maintainability, severity, coverage ve organizasyon trendlerini bir araya getiriyor. Mühendislik ekipleri bu verileri yeni debt oranı, remediation ratio ve escaped defect metrikleriyle birleştirerek sürdürülebilir bir kalite kültürü kurmalıdır.