Yazılım projelerinin %60’ı 3-5 yıl içinde “maintainability krizi”ne giriyor: kod karmaşıklaşıyor, refactor pahalı, yeni feature delivery hızı düşüyor. Bunun temel sebebi: ekiplerin code quality metric’lerini sistemli ölçmemesi. McKinsey Developer Velocity Index 2026’ya göre quality metric’leri sürekli izleyen ekipler, izlemeyenlere göre %37 daha hızlı feature delivery yaparken %48 daha az production bug üretiyor. Modern bir code quality stack (SonarQube + CodeScene + DORA + custom metric’ler) kod sağlığını sürekli ölçer ve büyük teknik borç birikimini önler. Türkiye’de yazılım ekiplerinin %34’ü SonarQube/SonarCloud kullanıyor; geri kalanı manuel review’a güveniyor — ölçeklendiğinde bu yaklaşım kırılıyor.
Bu rehberde modern code quality metric’lerini, ölçüm araçlarını, behavioral analiz (CodeScene) yaklaşımını, CI/CD entegrasyonunu ve technical debt yönetimini somut sayılarla aktarıyoruz. Senior engineers, tech leads ve engineering manager’lar için kod sağlığını ölçülebilir hale getirmenin somut yolu.
Code Quality Felsefesi: Ne Ölçüyoruz, Niçin?
Code quality salt teknik bir konu değil — şirket stratejisinin teknik yansıması. Yüksek quality bar yeni feature delivery’sini yavaşlatır gibi görünür ama orta-uzun vadede tam tersi: technical debt biriken bir codebase, 18 ay sonra her yeni feature için %40-60 daha fazla effort gerektiriyor. Code quality discipline’ı erken kurmamanın bedeli geometrik olarak büyüyor.
Modern code quality ölçümünün üç farklı katmanı var: (1) Statik analiz (SonarQube, ESLint) — kodun yapısal özellikleri. (2) Behavioral analiz (CodeScene) — kodun nasıl evrildiği. (3) Delivery analiz (DORA, SPACE) — kodun pratikte nasıl perform ettiği. Üçünü birlikte ölçen ekip, tek katmana bakanlara göre %37 daha hızlı maintainability eğrisine ulaşıyor.
Klasik Code Quality Metric’leri
- Cyclomatic Complexity: Fonksiyon başına karar sayısı. < 10 iyi, > 20 refactor sinyali.
- LOC (Lines of Code): Fonksiyon < 50, dosya < 500. Tek başına yanıltıcı — bağlamla yorumla.
- Code Duplication: %5’in altı hedef. Türev ihtimali yüksek pattern’ler için DRY uygulanmalı.
- Test Coverage: Unit %85+, integration %70+. Tek başına quality göstergesi değil.
- Cognitive Complexity: Okunabilirlik bazlı (SonarQube metric). < 15 hedef.
- Maintainability Index: 0-100 skala. > 65 iyi.
- Mutation Score: Test’lerin “false positive olmayan” hassasiyeti. PIT, Stryker, mutmut araçları.
Modern Behavioral Metric’ler (CodeScene)
- Hotspots: Sık değişen + karmaşık kod parçaları. 80/20 kuralı: %20 hotspot kod %80 bug’ları üretiyor.
- Knowledge Distribution: Tek geliştirici bağımlılığı. “Bus factor” ölçüsü.
- Temporal Coupling: Birlikte değişen dosyalar (gizli bağımlılık).
- Code Health trend: Zamanla artıyor mu azalıyor mu? Trend tek sayıdan daha bilgilendirici.
- Team coupling: Ekipler arası kod sahipliği örtüşmesi.
- Dev frequency vs complexity scatter: “Sık dokunulan karmaşık kod” red zone — öncelik bu olmalı.
Araç Stack
| Tool | Best for | Lisans | Tipik Yıllık Maliyet |
|---|---|---|---|
| SonarQube / SonarCloud | Quality gates, CI integration | Community / Enterprise | 0 / 10K-50K USD |
| CodeScene | Behavioral analysis, team metrics | Commercial | 15K-60K USD |
| CodeClimate | SaaS, PR feedback | Commercial | 10K-40K USD |
| Codacy | SaaS quality + security | Commercial | 8K-35K USD |
| Qodana (JetBrains) | IntelliJ ekosistemi | Commercial / Community | 0 / 10K-25K USD |
| ESLint + Prettier + Husky | JS/TS, açık kaynak, pre-commit | Açık kaynak | 0 |
| Pylint, Ruff, Black | Python | Açık kaynak | 0 |
| RuboCop, RSpec | Ruby | Açık kaynak | 0 |
CI/CD Entegrasyon
- Quality Gate: SonarQube ile her PR check.
- Failing gate → PR merge yasaklanır.
- Trend tracking dashboard (haftalık team review).
- Test coverage delta (yeni kod %X üstü test edilmeli — örn. %80 üstü).
- “New code first” — eski legacy code’a hücre koy ama yeni kod yüksek standartta.
- Pre-commit hook (Husky + lint-staged) — local’de kontrol, CI’ye uzak kalmasın.
- Branch protection: main’e doğrudan push yasak, PR + review + check zorunlu.
Technical Debt Yönetimi
- Quantify: SonarQube “TD remediation time” tahmin (saat cinsinden).
- Prioritize: Hot spot + business value matrix.
- Pay-down budget: Her sprint %15-25 TD task. Capacity planning rehberimizde buffer hesabını detaylandırdık.
- “Boy Scout Rule”: Bulduğun kodu temiz bırak.
- Architecture refactor: Yılda 1-2 büyük campaign, planlama ile.
- TD ratio < %5 sağlıklı, %5-15 dikkat, %15+ kritik müdahale gerek.
- Quarterly TD review meeting — engineering leadership zorunlu katılım.
Hangi Metrik Yanıltıcı?
- LOC / dev başına: productivity ölçmüyor. Senior dev daha az LOC üretir ama daha çok değer.
- Sadece test coverage %: kalitesini ölçmüyor (mutasyon testi gerek).
- Commit sayısı: aktivite, output değil.
- Bug count: tek başına anlam ifade etmez — severity + age daha bilgilendirici.
- PR sayısı: PR boyutu önemli (200-400 LOC ideal, 800+ red flag).
- Story point velocity tek başına: kalite trade-off’unu görünmez yapıyor.
Code Review Metric’leri
- Time to first review: < 4 saat hedef. PR’ın 24+ saat beklemesi context kaybı.
- PR size: ideal 200-400 LOC. 800+ “draftla parçala” sinyali.
- Comment density: çok yüksek → karmaşık kod ya da junior PR’ı.
- Approval rate: ilk gönderimde merge oranı. %30+ rework normal, %60+ rework process sorunu.
- Review yapan dağılımı: tek kişi mi, ekipte mi? “Bus factor” zayıflığı.
- Cycle time: PR open → merged. Elite ekiplerde < 1 gün.
AI-Augmented Code Review
2024-26 arası code review pratiği büyük dönüşüm yaşadı. CodiumAI, Greptile, Cursor BugBot, Sourcery, GitHub Copilot Workspace gibi araçlar PR’a otomatik comment ekleyerek “ilk pass” review yapıyor. McKinsey 2026 raporuna göre AI-augmented review human review yükünü %35 azaltıyor, false positive rate düşük (8-12%) ve “stylistic” yorumların büyük kısmı otomatize ediliyor — insan reviewer mimari ve business logic’e odaklanabiliyor.
Önerilen kurulum: PR açıldığında AI bot ilk 5-15 dakikada otomatik review + suggestion bırakır; insan reviewer 4-24 saat içinde “büyük resim” katmanını ele alır. AI bot’unun yanılgı tehlikesi: false sense of security — “AI onayladı, demek ki güvenli” mantığı. Critical PR’larda insan review tek başına yetmediği gibi AI review da yetmiyor; AI code generation rehberimizde bu dengeyi detaylandırdık.
Türkiye Pazarında Code Quality Pratikleri
- Türk yazılım ekiplerinin %34’ü SonarQube/SonarCloud kullanıyor, %21’i CodeClimate veya Codacy SaaS tercih ediyor; geri kalanı manuel review’a güveniyor.
- CodeScene gibi behavioral analiz araçları daha az yaygın (%7) — ölçek büyüdükçe ihtiyaç fark ediliyor.
- Türkiye’de yerli code quality SaaS rakibi yok; tüm araçlar yurtdışı, USD fiyatla satılıyor — kur riskine açık.
- Kamu ihalelerinde “code quality raporu” giderek zorunlu hale geliyor (özellikle ISO 27001 + KVKK denetim için).
- Türk yazılım hizmet şirketleri için “müşteriye SonarQube dashboard erişimi vermek” sözleşme avantajı sağlayan modern bir farklılaştırma.
Quality Champion Modeli
Code quality’i operasyonel düzeyde işletmek için “champion” rolü etkili: her ekipte 1 gönüllü senior dev (rotation ile değişebilir) quality stack’in maintenance’ından, threshold ayarlarından ve aylık trend raporundan sorumlu. Champion rolü:
- Sprint planning’de quality task’lerini sahipleniyor (TD pay-down budget’ı).
- Quarterly code quality retrospective hazırlıyor — “geçen çeyrek ne değişti?” raporu.
- Yeni mülakat sorularını + onboarding kit’ini güncelliyor.
- Tool vendor ilişkisini yönetiyor (lisans, support tickets).
- Engineering all-hands’de quality trend’lerini sunuyor — görünürlük yaratıyor.
Champion rolüne 3-6 ay süreli rotation pratik: hem birden fazla senior’a perspective veriyor hem burnout’u önlüyor.
Sık Sorulan Sorular
SonarQube self-hosted mi SaaS mi?
Açık kaynak self-hosted yeterli orta ölçekte. SonarCloud yıllık kurum 10K USD seviyesi. Multi-language + enterprise dashboard için commercial. Self-hosted bakım maliyeti 1 mühendis-yıl %5-10; hesaba katılmalı.
Test coverage hedefi %100 mü?
Hayır. %85 sweet spot. %100 hedefler gereksiz mock + test theater’a yol açar. Mutation testing daha değerli — gerçek test hassasiyetini ölçüyor.
Legacy code’da quality gate uygulamak mantıklı mı?
Eski koda dokunmak yerine “new code” baseline’ı koy. Yeni eklenen/değişen kod yüksek standartta. Eski kod hot spot olduğunda refactor — “Boy Scout Rule” yeterli, “tüm legacy’i temizleyelim” projeleri her zaman başarısız.
AI code review tool’lar code quality’i değiştiriyor mu?
Evet. Codium AI, Sourcery, GitHub Copilot review: insan review’dan önce ilk pass. Manuel review yükü %35 azalıyor. Ama: AI false negative riski var, kritik PR’larda insan review zorunlu.
Code quality’i performance review’a bağlamak doğru mu?
Dikkatli olmalı. Bireysel “sonar warning count” gibi metric’ler Goodhart’s Law’a kurban gider; dev’ler gerçek iyileştirme yerine metric’i optimize ediyor. Takım seviyesinde quality trend daha sağlıklı. Career ladder rehberimizde hangi metric’lerin promotion’a bağlanabileceğini anlattık.
Hotspot’ları nasıl önceliklendirelim?
CodeScene 2×2 matrix: complexity (yüksek) × change frequency (yüksek) = red zone. Bu zone’daki kodlar refactor önceliği. “Yıllarca dokunulmamış karmaşık kod” rahatsız edici ama acil değil — gerçek risk “sık dokunulan ve karmaşık” kombinasyonunda.
Ömer Önal’dan pratik not: Türkiye’deki yazılım ekiplerine code quality stack kurulumu danışmanlığı verdiğimde en sık karşılaştığım resistance, “SonarQube false positive’leri ekibi yoruyor” itirazı. Doğru ama eksik: tool’u out-of-the-box bırakırsanız gerçekten yoruyor; doğru pratik tool’u şirkete kalibre etmek. İlk hafta “noise” kuralları off-line yapın (genelde 40-60 kural), “high severity” alanı ekibinizin acı çektiği gerçek pattern’lara odaklayın (örn. SQL injection, async/await misuse, null safety). Bu kalibrasyon yapılmamışsa “quality gate” sembolik olur, ekip “rubber stamp”le geçirir. İkinci kritik nokta: code quality metric’lerini bireysel performans değil takım seviyesinde sahiplenin. “Şu mühendis 18 issue açtı” değil “şu modülün code health skoru bu çeyrekte %12 düştü” framing’i. Sizin ekibinizde quality gate aktif mi yoksa “PR review imzası” değer mi kazandı?
Sonuç
Code quality metrics, technical debt yönetiminin objektif temeli. Doğru kurulum (SonarQube + CodeScene + CI quality gate + sprint başına %15 TD budget + AI-augmented review) ile maintainability krizi %70 azalır, feature delivery hızı sürdürülebilir kalır, ekip moral düşmez. ADR pratikleri, OKR + KPI çerçevesi ve capacity planning birlikte ele alındığında kalite + hız + sürdürülebilirlik dengelenir. İletişim formundan projeniz için code quality assessment talep edebilirsiniz.
Dış otorite kaynaklar: SonarSource · CodeScene · McKinsey Developer Velocity · ThoughtWorks Insights
Ömer ÖNAL
Mayıs 17, 2026Türkiye’de code quality stack kurulumu yaptığım Türk mühendislik ekiplerinde gözlemlediğim en kritik dönüm noktası, “tool seçimi” değil “ilk 6 hafta kalibrasyon disiplini”. SonarQube’ı default kurallarla devreye alırsanız ekip 200+ “false positive” görünen warning ile tıkanıyor ve 3 ay içinde “bypass kültürü” yerleşiyor. Pratik öneri: ilk hafta default kural setinin %30-40’ını noise olarak işaretleyip kapatın; sadece “high impact” kuralları aktif tutun (örn. SQL injection, deprecated API, async misuse). İkinci kritik nokta: code quality metric’lerini bireysel performans review’a bağlamayın — Goodhart’s Law devreye giriyor ve ekip metric’i optimize ediyor, gerçek kalite iyileşmiyor. Onun yerine “module health trend” ve “hotspot count” gibi takım seviyesinde indikatörler kullanın. Sizin ekibinizde SonarQube quality gate aktif mi yoksa “PR’a yorum bırakır ama merge engeli yok” pattern’inde mi?