Etkili PR Review Kültürü Kurmanın 6 Yolu

Pull request (PR) incelemesi çoğu ekipte iki uç arasında gidip gelir: Ya günlerce bekleyen, yorumları kişisel eleştiriye dönen bir darboğazdır ya da kimsenin gerçekten okumadığı bir "onayla geç" törenidir. İyi kurulmuş bir review kültüründe ise inceleme, hatanın üretime ulaşmadan yakalandığı, bilginin ekip içinde yayıldığı ve kod tabanının ortak sahiplenildiği yerdir. Bu yazıda bu kültürü kurmanın altı yolunu ele alıyoruz.

1. PR'ları Küçük ve Tek Amaçlı Tutun

İnceleyenin dikkati sınırlıdır. Bin satırlık bir değişikliği açan kişi, çoğu zaman ya yüzeysel bir okuma yapar ya da incelemeyi "sonra bakarım" diye erteler. Küçük bir PR ise tek oturumda anlaşılır, yorumlar somut olur ve geri dönüş hızlanır.

Herkese uyan bir satır sınırı yok; ölçü, değişikliğin tek bir amaca hizmet etmesidir. Pratikte işe yarayan alışkanlıklar:

• Yeniden düzenlemeyi (refactor) davranış değişikliğinden ayırın. Önce "hiçbir davranış değişmedi" diyen bir PR, ardından yeni özelliği ekleyen ikinci bir PR.
• Büyük işleri dikey dilimlere bölün. Veritabanı göçü, servis katmanı ve arayüz ayrı PR'lar olarak sırayla gelebilir.
• Yarım işi feature flag arkasında birleştirin. Böylece uzun ömürlü dallar ve devasa birleştirmeler oluşmaz.
• Otomatik üretilen dosyaları ayırın. Kilit dosyaları ve üretilmiş kod, incelemeye değer satırların arasında kaybolmasın.

2. Açıklamada "Ne" Kadar "Neden"i de Yazın

Kod neyin değiştiğini zaten gösterir; göstermediği şey, değişikliğin neden bu şekilde yapıldığıdır. İnceleyen kişi bağlamı bilmediğinde ya yanlış şeyleri sorgular ya da kritik bir tasarım kararını fark etmeden geçer. Depoya bir PR şablonu eklemek bu bilgiyi alışkanlığa dönüştürür. GitHub'da .github/pull_request_template.md dosyası her yeni PR'ın açıklamasını önceden doldurur:

## Neden
Bu değişiklik hangi sorunu çözüyor? İlgili iş kaydı:

## Ne değişti
Önemli tasarım kararları ve değerlendirilen alternatifler:

## Nasıl test edildi
Otomatik testler, elle denenen senaryolar, ekran görüntüleri:

## Riskler ve geri dönüş
Göç, yapılandırma değişikliği veya feature flag var mı?

Açıklamayı yazmak, yazara da bir öz-inceleme fırsatı verir. PR'ı göndermeden önce kendi diff'inizi baştan sona okumak; unutulmuş log satırlarını, yorum satırına alınmış kodları ve alakasız değişiklikleri incelemeciden önce sizin yakalamanızı sağlar.

3. Makinenin Yapabileceği İşi İnsana Bırakmayın

Girinti, tırnak tipi ya da import sırası hakkında yazılmış her yorum, insan dikkatinin boşa harcanmasıdır. Bu tür kurallar araçlara devredildiğinde inceleme, gerçekten insan muhakemesi gerektiren konulara (doğruluk, tasarım, okunabilirlik, güvenlik) odaklanır.

• Biçimlendirme: Prettier gibi bir biçimlendirici, tercihen commit öncesinde otomatik çalışsın.
• Statik analiz: Linter ve tip denetimi (tsc --noEmit gibi) CI'da zorunlu olsun.
• Testler: Birim ve entegrasyon testleri her PR'da koşsun; arayüz bileşenlerinde görsel regresyon testleri de bu adıma eklenebilir.
• Bağımlılık ve sır taraması: Bilinen açıklar ve depoya yanlışlıkla eklenen anahtarlar otomatik yakalansın.

GitHub'da branch protection kuralları ya da rulesets ile bu kontrollerin geçmesini birleştirme şartı yapabilirsiniz. Kural basit olmalı: Kontroller kırmızıyken inceleme istenmez.

4. Yorumların Niyetini Açıkça Belirtin

Yazılı iletişimde ton kaybolur. "Bunu neden böyle yaptın?" cümlesi merak da olabilir, itiraz da. Yorumun niyetini baştan söylemek, hem yanlış anlaşılmayı hem de gereksiz tartışmayı azaltır. Bunun için ekip içinde ortak önekler kullanılabilir; Conventional Comments bu fikri standartlaştıran bir öneridir:

• engelleyici: Birleştirmeden önce çözülmesi gereken bir sorun (hata, güvenlik açığı, veri kaybı riski).
• öneri: Daha iyi olabileceğini düşündüğünüz ama yazara bırakılan bir değişiklik.
• soru: Anlamak için soruyorsunuz; bir değişiklik talebi değil.
• nit: Küçük, kozmetik bir not; görmezden gelinebilir.

Yorumlarda kişiyi değil kodu konuşun: "Burada hata yapmışsın" yerine "Bu fonksiyon boş liste geldiğinde undefined dönüyor gibi görünüyor." Beğendiğiniz bir çözümü belirtmek de review'in parçasıdır; yalnız eksik arayan bir inceleme, zamanla PR açmayı yorucu hâle getirir.

Bir tartışma iki üç yorumdan uzun sürüyorsa yazışmayı bırakıp kısa bir görüşme yapın, varılan kararı da PR'a not edin.

5. Hız İçin Ortak Bir Beklenti Belirleyin

Bekleyen bir PR, yazarın aklının iki iş arasında bölünmesi demektir. Dal eskidikçe çakışmalar artar, bağlam unutulur. Bu yüzden incelemeyi "boş vakit olunca yapılan iş" değil, ekibin önceliklerinden biri olarak görmek gerekir.

• Yanıt süresi için açık bir hedef koyun. Örneğin "ilk yanıt en geç bir iş günü içinde". İlk yanıt onay olmak zorunda değil; "öğleden sonra bakacağım" demek de belirsizliği kaldırır.
• İnceleyenleri otomatik atayın. CODEOWNERS dosyası, değişen dizinin sahiplerini PR'a kendiliğinden ekler.
• Bekleyenleri görünür kılın. Açık PR'ları yaşına göre listeleyen bir pano ya da sohbet kanalına düşen günlük bir özet, unutulan incelemeleri ortaya çıkarır.
• Onay sayısını riske göre ayarlayın. Çoğu değişiklik için bir onay yeterlidir; ödeme, yetkilendirme ya da veri göçü gibi hassas alanlarda iki onay ya da belirli bir kod sahibinin onayı istenebilir.

6. Review'i Öğrenme Alanına Çevirin

İnceleme yalnız kıdemlilerin kıdemsizleri denetlediği bir süreç olduğunda, ekibin daha az deneyimli üyeleri hep yalnızca yorum alan taraf olur. Oysa yeni katılan bir geliştiricinin kıdemli birinin PR'ını incelemesi, kod tabanını öğrenmenin en hızlı yollarından biridir; sorduğu "bu neden böyle?" sorusu da çoğu zaman belgelenmemiş bir varsayımı ortaya çıkarır.

• Herkes inceleme yapsın. Onay yetkisi kısıtlı olsa bile yorum yapmak herkese açık olsun.
• Büyük tasarım kararlarını PR'dan önce konuşun. Kod yazıldıktan sonra mimariyi tartışmak pahalıdır; kısa bir tasarım notu ya da taslak (draft) PR erken geri bildirim alır.
• Tekrarlayan yorumları kurala dönüştürün. Aynı uyarı üçüncü kez yazılıyorsa, bir lint kuralı ya da ekip rehberine bir madde olma vakti gelmiştir.
• Süreci düzenli gözden geçirin. Ayda bir kısa bir retrospektifte "hangi PR'lar takıldı, neden?" sorusunu sormak, kuralları ekibe göre ayarlamayı sağlar.

Sonuç

İyi bir review kültürü tek bir araçla ya da kuralla kurulmaz; küçük PR'lar, bağlam veren açıklamalar, otomasyona devredilmiş rutin kontroller, niyeti belli yorumlar, öngörülebilir yanıt süreleri ve öğrenmeye açık bir ekip birbirini besler. Hepsini aynı anda uygulamaya çalışmak yerine, ekibinizi en çok yavaşlatan noktadan başlayın ve birkaç hafta sonra etkisine birlikte bakın.