Code Review Kültürü: Bir Ekibi Yapan ya da Yıkan Pratik

İki ekip düşün. Aynı dili, aynı stack'i, aynı kıdemi paylaşıyorlar. Bir ekibin code'u yıllar geçtikçe daha temiz oluyor, ekibinin kıdemi yükseliyor, kod tabanı sürdürülebilir kalıyor. Diğeri tam tersi.

Aralarındaki en büyük fark code review kültürü.

Bu yazı, 13 yıl boyunca farklı code review kültürlerinde çalıştığım ve gözlemlediğim derslerden.

Code review nedir, ne değildir

Nedir:

• Bir öğrenme aracı
• Kod kalitesini ekip seviyesine taşımak
• Bilgi paylaşımı ("bu özellik niye var, nasıl çalışıyor")
• Bug yakalama (yan etki)

Değildir:

• Junior'ı eleştirme alanı
• Kişisel tercih dayatma
• Style/formatting'i tartışma alanı (ki bu işi linter yapar)
• Statü gösterisi

Ekibin bunu net bilmesi, kültürün kalıbı.

İyi review yorumu nasıl olur

Anatomisi

Bağlam + öneri + neden + alternatif (gerektiğinde):

"Bu fonksiyon 3 farklı şey yapıyor (validation, transformation, save). Tek tek ayrı fonksiyonlara bölelim — test yazması daha kolay olur, başkası bir parçayı reuse edebilir. Örnek: validateInput, transform, save. Ne dersin?"

vs.

"Bu fonksiyon çok uzun. Böl."

İlki başkasının düşünmesini sağlar. İkincisi ego'ya zarar verir, alternatif sunmaz.

Soru olarak sun

"Burası neden böyle?" "Burayı şöyle düşünebilir miydik?" — bu sorular davet eder. "Bu yanlış" iddialıdır, savunma uyandırır.

Yorum bir tartışma açar. İddia bir saldırı uyandırır.

Severity belirt

Her yorum aynı önemde değil. Belirt:

• blocking: bu PR merge olmamalı
• suggestion: değiştirebilirsin, ama merge'e engel değil
• nit: küçük detay, opsiyonel
• question: anlamak için soruyorum, change request değil

nit: ve q: kısaltmaları popüler. PR yazarı önceliklendirebilir.

Yazar olarak ne yapmalı

Kendin oku ilk

PR'ı açmadan önce kendi kodunu oku. GitHub'ta diff'e bak, başkası gözüyle. Bir sürü hata bulursun. Reviewer'a saygıdan da, hızdan da, kalitedden de — kendin oku.

Açıklayıcı PR description yaz

PR title'ında "fix bug" yazma. Description'da yaz:

## Ne değişti?
- Cache invalidation race condition'unu düzelttim

## Neden?
- High traffic'te aynı key 2 instance tarafından eş zamanlı yazılırsa stale veri oluşuyordu

## Nasıl test ettim?
- Yeni unit test eklendi (`test_concurrent_invalidation`)
- Local'de race scenario simüle edildi

## Risk?
- Düşük. Logic değişikliği lock'a sınırlı.

Bunu yazmak 5 dakika alır. Reviewer'ın PR'ı anlayıp doğru sorular sorabilmesi için kritik.

Konstrüktiv eleştiriye savunmasız aç ol

Yorumla aynı fikirde değilsen, açıkla. Aynı fikirde olduğunda, hemen kabul et. Tartışma kişisel olmadığı sürece devam edebilir.

"Bu mantıklı, değiştiriyorum" demek zayıflık değil, profesyonellik göstergesi.

Reviewer olarak ne yapmamalı

Style'ı yorumlama (linter işi)

prettier, eslint, black, gofmt — bu araçlar otomatik fix yapar. PR review'da style yorumu = ekibin tooling'i eksik. Önce o sorunu çöz, sonra kişiyi suçlama.

Tüm kararları yeniden açma

Yazarın yıllar önce verilmiş bir mimari karar üzerine kod yazıyor. PR review'da "Niye Redis kullanıyoruz" diye sormak yer değil. O tartışma ayrı, daha geniş forum'da yapılır.

Bilmediğin bir alanda otoriter olma

"Şu kütüphaneyi hiç kullanmamışım ama bence X yanlış" — bu yorumu yapma. Bilmiyorsan soru sor.

Geç yaparak engel olma

PR açıldıktan 24 saat sonra hâlâ review yapmadıysan, başka birine devret. Kişiyi 3 gün bekletme. Ekibin akışını kesiyorsun.

Hız: same-day review

PR aç → en geç 8 saat içinde ilk yorumu al. Bu, ekibin akışı için kritik.

Pratik:

• Sabah ilk iş: aç PR'a bak (kendin)
• Saat 11: review zamanı (sabah 30 dk)
• Saat 4: review zamanı (öğleden sonra 30 dk)
• Acil olansa Slack'te bilgilendir

Bu disiplin yoksa, herkes "bekleyen PR'lar" listesine bakar, kimse açmaz, motivasyon ölür.

Pair review

Karmaşık bir PR için yazılı review yetmez. 30 dakika çağır, ekran paylaş, beraber gez. Bu çok daha hızlı, daha derin, daha az surtüşmeli.

Yapılan iş: yazar koddan geçer, reviewer "burası neden?" diye sorar, gerçek zamanlı tartışılır. Yazılı review'da 5 yorum tur'u olarak gidecek olan iş 30 dakikada biter.

Sonuç

Code review kültürü teknik bir konu olmaktan çok takım kültürü konusu. İyi review = öğrenme + yükselme + saygı. Kötü review = ego + çatışma + suspicion.

Bu kültür ekibin liderlerinin tonuyla kurulur. Senior bir engineer review'da nasıl davranıyorsa, junior öyle yapar. İki sene sonra ekibin yarısı senior gibi yorum yazıyor olur — ya iyi yönde ya kötü yönde.

Hangisini istiyorsan, sen başla.