Code review'da nelere dikkat edersiniz? İyi bir pull request nasıl hazırlanır?

Code review'un amacı yalnızca hata yakalamak değil; kod kalitesini, bilgi paylaşımını ve tutarlılığı sağlamaktır. İnceleyen kişi önce büyük resme (tasarım, doğruluk), sonra detaylara (isimlendirme, stil) bakmalıdır.

İncelerken öncelik sırası

1. Doğruluk: kod gereksinimi karşılıyor mu? Kenar durumlar (null, boş liste, eşzamanlılık, hata yolları) düşünülmüş mü?
2. Tasarım: sorumluluklar doğru yerde mi? Gereksiz karmaşıklık veya tekrar var mı?
3. Güvenlik: girdi doğrulama, yetki kontrolü, SQL injection, log'a hassas veri yazılması.
4. Performans: N+1 sorgu, döngü içinde ağ çağrısı, gereksiz bellek kullanımı.
5. Testler: değişikliği gerçekten doğrulayan, okunabilir testler var mı?
6. Okunabilirlik: isimlendirme, fonksiyon uzunluğu, gerekli yerde açıklayıcı yorum.
7. Stil: bunlar mümkün olduğunca formatter ve linter'a bırakılmalı (Prettier, Black, ESLint, Checkstyle).

Yorum yazarken

• Kişiyi değil kodu eleştirin: "Bu fonksiyon iki işi yapıyor gibi" > "Yanlış yazmışsın".
• Nedenini açıklayın ve gerekirse alternatif önerin.
• Zorunlu olmayan önerileri nit: veya "opsiyonel" diye işaretleyin.
• İyi yapılmış kısımları da belirtin.
• Uzun bir tartışma başlıyorsa yazışmak yerine kısa bir görüşme yapın.

İyi bir PR hazırlamak

• Küçük tutun: genelde birkaç yüz satırın altında; büyük işleri ardışık PR'lara bölün. Büyük PR'lar yüzeysel incelenir.
• Açıklama yazın: ne değişti, neden değişti, nasıl test edildi, ekran görüntüsü veya log.
• Kendi PR'ınızı önce siz inceleyin: debug kodları, yorum satırına alınmış kodlar, ilgisiz format değişiklikleri.
• Refactoring ile davranış değişikliğini aynı PR'da karıştırmayın.
• CI'ın (test, lint, build) yeşil olduğundan emin olun.

Başlık: Sipariş listesinde N+1 sorgu sorununu gider

Neden: /orders endpoint'i 50 sipariş için 51 sorgu atıyordu (p95: 1.8 sn).
Ne: Order -> items ilişkisi için eager loading eklendi.
Test: Entegrasyon testi sorgu sayısını doğruluyor; lokal p95 210 ms.

Ölçülebilir hedefler

Google'ın mühendislik pratiklerinde vurgulandığı gibi, review'lar hızlı olmalıdır (ideal olarak bir iş günü içinde ilk yanıt). Yavaş review, geliştiricileri büyük PR açmaya iter.