Kod İncelemesinde Geri Bildirimi Yazıya Dökmenin Yolu

Kod incelemesinde en çok zaman kaybettiren şey teknik anlaşmazlık değil, geri bildirimin nasıl yazıldığıdır. Aynı itiraz iki farklı cümleyle ifade edildiğinde biri beş dakikada çözülür, diğeri iki günlük bir gerginliğe dönüşür. Bu fark ölçülebilir: birleştirme süresi, yorum sayısı ve tekrar açılan tartışmalar.

Sorun 1: bağlayıcılığın belirsiz olması

"Burada erken dönüş kullanılabilir" cümlesi bir zorunluluk mu, bir öneri mi? Yazan kişi öneri kastetmiştir; okuyan kişi genellikle zorunluluk anlar ve gereksiz bir değişiklik yapar. Çözüm etiket kullanmaktır.

**engel:** Bu sorgu kullanıcının kendi kaydı mı diye kontrol etmiyor;
başka kullanıcının siparişi görüntülenebilir. Birleştirmeden önce
`where('user_id', $kullaniciId)` eklenmeli.

**öneri:** Bu üç `if` bloğu erken dönüşe çevrilirse girinti azalır.
Zorunlu değil, sonraki dokunuşta da yapılabilir.

**soru:** Bu koşul neden `>=` yerine `>`? Sınır durumu bilinçli mi?

**övgü:** Hata mesajına kullanıcı kimliğini eklemişsin, üretimde
bunu aramak zaman kazandıracak.

Dört etiket, yorumun ağırlığını tahmin etmeyi ortadan kaldırır. Etiketsiz bir incelemede yazar her yorumu zorunluluk sayar, bu da gereksiz iş ve gecikme üretir.

Sorun 2: gerekçesiz talep

"Bunu servise taşı" cümlesi bir emirdir ve tartışılabilir bir zemin bırakmaz. Gerekçe eklendiğinde aynı cümle bir argümana dönüşür ve karşı taraf ya ikna olur ya da gerekçeye itiraz eder — her ikisi de ilerlemedir.

✗ "Bu mantığı servise taşı."

✓ "**öneri:** Bu hesap iki farklı controller'da tekrarlanıyor
   (SiparisController:88 ve RaporController:142). Servise taşınırsa
   iş kuralı değiştiğinde tek yerde güncellenir."

Sorun 3: koda değil kişiye yönelmek

"Neden böyle yaptın?" ile "Bu yaklaşım şu durumda ne yapar?" arasındaki fark, aynı bilgiyi istemekle savunma refleksi tetiklemek arasındaki farktır. Özneyi koda taşımak küçük bir dil alışkanlığıdır ama tartışmanın seyrini değiştirir.

Sorun 4: üçüncü tura giden tartışma

Yazılı geri bildirimin sınırı vardır. Aynı konuda iki tur yorum gidip geldiyse mesele artık teknik değil, bağlam farkıdır. Üçüncü tura girmek yerine on beş dakikalık bir görüşme, tartışmayı bitirir ve kararı yazılı olarak inceleme sayfasına not düşersiniz.

# İncelemelerin ne kadar sürdüğünü ölçün: his değil veri
gh pr list --state merged --limit 50 \
  --json number,createdAt,mergedAt,reviews \
  | jq -r '.[] | "\(.number)\t\((((.mergedAt|fromdate) - (.createdAt|fromdate))/3600)|floor) saat\t\(.reviews|length) inceleme"'

Bu ölçüm, "incelemeler yavaş" hissini tartışılabilir bir sayıya çevirir. Uzaktan çalışan ekiplerde yazılı iletişimin ağırlığı daha da artar; uzaktan ekipte yazılı iletişim yazımız bu tarafı ele alıyor.

İnceleyen için üç kural

Önce büyük resme bakın. İsimlendirme yorumuna girmeden önce yaklaşımın doğru olup olmadığına karar verin; mimari itiraz en sona bırakılırsa yazar boşa emek harcamış olur.

Otomatikleştirilebilir olanı yorumlamayın. Girinti, boşluk ve import sırası biçimlendiricinin işidir; bunları elle yazmak hem zaman kaybı hem gürültüdür.

Hızlı dönün. Bir günü aşan inceleme, yazarın bağlamını kaybetmesine yol açar; aynı yorum ertesi gün iki kat daha uzun sürede çözülür.

Yazan için iki kural

İncelemeyi kolaylaştırmak yazarın sorumluluğudur: değişikliği küçük tutun ve açıklamada neden yaptığınızı yazın. Ne yaptığınız zaten diff'te görünür. Küçük ve odaklı değişiklikler ayrıca hata aramayı da kolaylaştırır. Kariyer tarafında bu becerinin ağırlığı için junior'dan mid-level'a geçiş yazımıza bakabilirsiniz. Ne tür konuların incelemeye değdiğini kod incelemesinde neyi nasıl eleştirmeli yazımızda listelemiştik; sürecin genel çerçevesi için Google'ın mühendislik pratikleri belgesi yaygın bir referanstır.

Sonuç

Kod incelemesinin kalitesini belirleyen şey, inceleyenin teknik derinliğinden çok yazdığı cümlenin netliğidir. Dört küçük alışkanlık farkı yaratır: yorumu etiketleyip bağlayıcılığını belirtin, her talebi gerekçelendirin, özneyi kişiden koda taşıyın ve iki turda çözülmeyen konuyu görüşmeye taşıyın. Bunlar nezaket kuralları değil, verimlilik kurallarıdır — birleştirme sürenizi ölçtüğünüzde etkisini sayıyla göreceksiniz. Bir sonraki incelemenizde yalnızca etiket eklemeyi deneyin; tek başına bu değişiklik bile gereksiz yapılan işi belirgin biçimde azaltır.

Pratik Uygulama Kontrol Listesi

Bu yazıdaki önerileri kendi ekibinize uyarlarken aşağıdaki adımları sırasıyla uygulamanız, teoriden pratiğe geçişi kolaylaştırır:

1. Mevcut durumu ölçün. Değişiklik yapmadan önce bugünkü performansı/süreyi/hata oranını kaydedin; aksi halde iyileşmeyi kanıtlayamazsınız.
2. Küçük bir pilot seçin. Tüm sisteme veya tüm ekibe birden uygulamak yerine tek bir modülde veya tek bir sprintte deneyin.
3. Sonuçları ekiple paylaşın. Elde ettiğiniz veriyi (olumlu ya da olumsuz) kısa bir notla ekibe aktarın; kararın gerekçesi belgelenmemişse aynı tartışma birkaç ay sonra tekrar açılır.
4. Süreci tekrarlanabilir hale getirin. İşe yarayan pratiği bir kontrol listesine veya şablona dönüştürün ki yeni katılan ekip üyeleri de aynı standardı hızlıca öğrensin.

Sık Yapılan Yanlışlar

Bu konuda ekiplerin en çok düştüğü tuzak, çözümü tek bir kişiye ya da tek bir araca yüklemektir. Oysa kalıcı iyileşme, sürecin ekibin günlük rutinine (code review kontrol listesi, sprint planlama, onboarding dokümanı gibi) gömülmesiyle mümkün olur. İkinci yaygın hata ise "en iyi pratiği" olduğu gibi kopyalamaktır — başka bir ekipte işe yarayan bir yaklaşım, farklı bir ölçekte veya farklı bir teknoloji yığınında aynı sonucu vermeyebilir; önce kendi bağlamınızda küçük ölçekte test edin, sonra genişletin. Üçüncü tuzak ise ölçmeden karar vermektir: "daha iyi hissettiriyor" öznel bir gerekçedir, ekip içi tartışmalarda nesnel veriyle desteklenmeyen kararlar er ya da geç sorgulanır ve geri alınır. Son olarak, dokümantasyonu atlamak da sık görülen bir hatadır: bir kararın "neden" alındığı yazılı değilse, ekip altı ay sonra aynı tartışmayı sıfırdan yeniden yapmak zorunda kalır ve önceki deneyimden öğrenilenler kaybolur.

Sonuç

Kod İncelemesinde Geri Bildirimi Yazıya Dökmenin Yolu konusunda burada değindiğimiz noktalar, konuyu ilk kez ele alan ekipler için de deneyimli geliştiriciler için de pratik bir kontrol listesi görevi görür. geri bildirim üzerine çalışırken en çok fayda sağlayan yaklaşım, tek seferde her şeyi mükemmelleştirmeye çalışmak yerine küçük, ölçülebilir adımlarla ilerlemektir. Ekibinizde bu konuyu bir sonraki sprint retrospektifinde veya teknik tartışma toplantısında gündeme getirmenizi, burada anlatılan pratiklerden hangilerinin sizin bağlamınıza uyduğunu birlikte değerlendirmenizi öneririz. Sonuç olarak, doğru araçları seçmek kadar bunları ekip kültürüne oturtmak da başarıyı belirleyen asıl etkendir.