Code Review — nedir, kod incelemesi ve PR kontrolü nasıl çalışır

Code Review Nedir

Code review, entegrasyondan önce meslektaşlar tarafından kodun sistematik olarak kontrol edilmesidir. Git bağlamında bu, bir geliştiricinin değişikliklerle bir pull request oluşturması, incelemeciler ataması ve onların diff'i incelemesi, yorum bırakması ve karar vermesi anlamına gelir. Bir incelemcci değişiklik talep edebilir, PR'ı onaylayabilir veya genel bir yorum bırakabilir.

Kod incelemesi beş hedefi takip eder: kod kalitesini artırmak (hataları üretime ulaşmadan bulmak), bilgiyi yaymak (incelemeci yeni yaklaşımlar öğrenir, yazar geri bildirim alır), standartlara uyumu sağlamak (kod stili ve mimari kararlara uygunluğu kontrol etmek), bus factor'ü azaltmak (birden fazla geliştirici kodu bilir) ve sorumluluk kültürü oluşturmak (yazar, kodun inceleneceğini bilerek daha dikkatli yazar).

Kod incelemesinin zıttı kör committir: bir geliştirici inceleme olmadan paylaşılan bir dala değişiklik gönderir. Bu yaklaşım yalnızca tek geliştiricili projelerde veya sonradan inceleme ile acil düzeltmeler için kabul edilebilir. Profesyonel ekip geliştirmede, kod incelemesi belgeler ve yapılandırma güncellemeleri dahil her değişiklik için zorunlu bir adımdır.

Code Review'de Ne Kontrol Edilir

Kod incelemesi sistematik olmalı, kaotik değil. Deneyimli incelemeciler kodu belirli bir sırayla kontrol eder: önce mimari ve mantık, sonra testler, ardından güvenlik ve performans ve en sonunda — stil ve adlandırma. Bu sıra, incelemeci yorulmadan kritik sorunların fark edilmesini sağlar.

Mimari ve mantık: kod görevi çözüyor mu, aşırı soyutlamalar var mı, SOLID ve DRY ilkelerine uyuluyor mu? İlk okumada anlaşılması zor olan karmaşık kod, yeniden düzenleme gerektiğinin bir işaretidir. İncelemeci, kodun görevin belirttiği şeyi tam olarak yaptığından ve sorumluluğu dışında yan etkileri olmadığından emin olmalıdır.

Testler: yeni testler tüm senaryoları kapsıyor mu — olumlu, olumsuz, sınır durumları. Değişikliklerden sonra mevcut testler geçiyor mu. Tutarsız bir şekilde başarısız olan dengesiz testler var mı? Güvenlik: SQL enjeksiyonu, XSS, günlükler veya API yanıtları aracılığıyla hassas veri sızıntılarının olmaması. Performans: algoritma verimliliği, aşırı veritabanı sorguları, kaynak sızıntıları.

• Mimari — çözümün doğruluğu, SOLID uyumu, aşırı mühendislik olmaması.
• Mantık — hatalar ve sınır durumları dahil tüm senaryoların işlenmesi.
• Testler — yeni değişikliklerin kapsamı, mevcut testlerin bozulmaması.
• Güvenlik — enjeksiyon, XSS, CSRF, günlükler yoluyla veri sızıntıları.
• Performans — algoritma karmaşıklığı, N+1 sorguları, bellek sızıntıları.

İnceleme Boyutu: Neden 400 Satır Maksimum

PR boyut sınırı, kod incelemesi etkinliğinin en önemli metriğidir. Cisco (2015) tarafından yapılan bir araştırma ve SmartBear ile Google'ın sonraki deneyleri, inceleme hacmi 400 satırı aştığında incelemecinin hata bulma yeteneğinin keskin bir şekilde düştüğünü gösterdi. Bir PR 400 satırı aşarsa, hatalar rastgele olasılıktan daha yüksek olmayan bir şekilde tespit edilir.

Optimal boyut: PR başına 200–400 satır. Bu hacim, konsantrasyonu koruyarak 30–60 dakikada incelenebilir. Google, tam konsantrasyonla inceleme turu başına 200 satırdan fazla olmamasını önerir. Değişiklikler daha büyükse, görev her biri mantıksal olarak tamamlanmış bir değişiklik getiren birkaç ardışık PR'a ayrılmalıdır.

İnceleme süresi: PR oluşturulduktan sonra 24 saat içinde. İnceleme birkaç gün sürerse, görev bağlamı kaybolur ve yazar yorumlara yanıt verirken bağlamı geri yüklemek için zaman harcamak zorunda kalır. Güçlü kod incelemesi kültürüne sahip ekipler, inceleme için SLA'lar belirler: örneğin, kritik değişiklikler için 4 saat ve normal değişiklikler için 24 saat.

İyi İnceleme Yorumları Nasıl Yazılır

Yorumların tonu, kod incelemesinin etkinliği için kritik öneme sahiptir. “Bu yanlış” gibi bir yorum savunmacı bir tepkiye neden olur ve yazara yararlı bilgi sağlamaz. Daha iyi bir ifade, soru-öneri şeklidir: “Bu yaklaşım hakkında ne düşünüyorsunuz?”, “user == nil ise bu bir NPE'ye neden olabilir. Belki bir guard eklemeli?”. Sorular daha az çatışmacıdır ve tartışmayı teşvik eder.

İyi bir yorum üç bölümden oluşur: neyin yanlış olduğu, neden sorun olduğu ve nasıl düzeltileceği. Örnek: “Bu döngü, iç içe contains nedeniyle O(n²) kullanıyor ve 10k+ kayıtta yavaşlayabilir. O(1) arama için bir Set ile değiştirmeyi deneyin.” Bu ifade aynı anda sorunu tanımlar, önemini açıklar ve bir çözüm önerir — yazar tahmin etmek zorunda kalmaz.

GitHub ve GitLab önerileri destekler — satır içi kod değişikliği önerileri. Bir incelemeci “```suggestion Filter empty strings before processing```” yazabilir ve yazar tek tıklamayla değişikliği uygulayabilir. Bu, küçük düzeltmeleri hızlandırır ve inceleme tur sayısını azaltır. Büyük değişiklikler için, bir öneriye büyük bloklar yerleştirmektense genel bir yorum yazmak daha iyidir.

# İyi kod incelemesi yorumu şablonu

# KÖTÜ: "This code is wrong"
# İYİ: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub öneri sözdizimi:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Ekipte Code Review İş Akışı

Etkili bir inceleme iş akışı dört aşama üzerine kuruludur. Birinci — yazar PR'ı hazırlar: net bir başlık yazar (örneğin, “feat: add password reset screen”), değişikliklerin açıklamasını, izleyicideki göreve bağlantıları ve test talimatlarını ekler. İkinci — yazar, otomatik atama (CODEOWNERS tabanlı) veya manuel olarak incelemeciler atar.

Üçüncü aşama — incelemeci kodu kontrol eder ve yorum bırakır. Dördüncü — yazar düzeltmeler yapar, yorumlara yanıt verir ve yeniden inceleme talep eder. Onay alınana kadar döngü tekrarlanır. Onaydan sonra yazar birleştirmeyi gerçekleştirir (veya bot yapar). Mergify veya GitHub Auto-merge aracılığıyla otomasyon son aşamayı hızlandırır.

Önemli bir iş akışı öğesi — bayat PR yönetimidir. Bir PR 3 günden fazla inceleme olmadan kalırsa, süreç bloke olur. Çözümler: incelemeci rotasyonu (atanan incelemeci müsait değilse), Slack/Teams aracılığıyla bildirimler, inceleme süresi sınırı (SLA). Bazı ekiplerde, 7 günden fazla incelemesiz PR otomatik olarak kapatılır ve yazar main ile senkronize olduktan sonra yeni bir tane oluşturur.

• PR oluşturma — net başlık, açıklama, görev bağlantıları, UI değişiklikleri için ekran görüntüleri.
• Atama — CODEOWNERS aracılığıyla otomatik atama veya 1–2 incelemecinin manuel seçimi.
• İnceleme — sırayla kontrol: mimari → mantık → testler → güvenlik → stil.
• Düzeltmeler — yazar tüm yorumlara yanıt verir, engelleyen sorunları düzeltir, yeniden inceleme talep eder.
• Birleştirme — onay ve yeşil CI'dan sonra yazar veya bot birleştirmeyi gerçekleştirir.

Yaygın Code Review Hataları

İlk hata — yüzeysel inceleme. İncelemeci mantığa dalmadan diff'i hızla tarar ve Onayla'ya tıklar. Nedenler: büyük PR, son tarih, yorgunluk. Sonuçlar: hatalar üretime ulaşır. Çözüm: kaliteli bir inceleme için zaman yoksa — resmi bir onay yerine dürüstçe “Bugün inceleyemiyorum, yarına erteleyin” yazın.

İkinci hata — aşırı eleştiri (nitpicking). İncelemeci biçimlendirme stili, değişken adlandırma, önemsiz ayrıntılar hakkında düzinelerce yorum bırakır. Bu, yazarın motivasyonunu düşürür ve incelemeyi uzatır. Çözüm: StyleGuide ve linter'ler stili otomatik olarak kontrol etmelidir. İncelemede insan mantık, mimari ve güvenliği kontrol eder.

Üçüncü hata — soru sormayan inceleme. İncelemeci yalnızca Request Changes ve Approve yayınlıyor ancak soru sormuyorsa, yeni bir şey öğrenme fırsatını kaçırır. Sağlıklı bir kod incelemesinin en iyi göstergesi, her iki tarafın da yeni bir şey öğrendiği tartışmaların varlığıdır. Bir inceleme bir katılımcının monoloğuysa, süreç bozuktur.

• Yüzeysel inceleme — derin analiz olmadan Onayla. Çözüm: zamanınız yoksa incelemeyin.
• Nitpicking — linter tarafından kontrol edilmesi gereken stili eleştirmek. Çözüm: stil kontrollerini otomatikleştirin.
• Kişisel tercih — “Ben farklı yazardım”. Çözüm: kod çalışmalı, incelemecinin beğenisini kazanmak zorunda değil.
• Gecikme — 24 saatten uzun inceleme. Çözüm: incelemede SLA, ihlalde yükseltme.
• Bağlamı yok sayma — görevi anlamadan kodu incelemek. Çözüm: diff'ten önce PR açıklamasını okuyun.