Code Review Kılavuzu
Code review, kod kalitesini artırmak, bilgi paylaşımını sağlamak ve ekip olarak birlikte öğrenmek için kritik bir pratiktir. Review sadece bug yakalamak değil, aynı zamanda daha iyi mühendisler olmak içindir.
Neden Code Review?
- Kalite: Bugları üretimden önce yakala
- Bilgi paylaşımı: Codebase bilgisi tek kişide kalmasın
- Öğrenme: Hem yazar hem reviewer öğrenir
- Tutarlılık: Kod standartları ve pattern'ler tutarlı kalsın
- Ownership: Birden fazla kişi kodu tanısın
Yazar İçin Kurallar
PR Açmadan Önce
- Kendi kodunu kendin review et (self-review)
- Testlerin geçtiğinden emin ol
- Lint/format hataları temizlenmiş olmalı
- PR küçük olsun: ideal <400 satır değişiklik
- Bir PR bir iş yapsın (tek sorumluluk)
İyi PR Açıklaması
- Ne yaptın: Değişikliğin özeti
- Neden yaptın: İş gereksinimi veya problem
- Nasıl test edilir: Reviewer için adımlar
- Riskler: Potansiyel yan etkiler
- Ekran görüntüsü/video: UI değişiklikleri için
PR açıklaması boş bırakılmaz. 'Bug fix' gibi tek kelime açıklamalar kabul edilmez.
Reviewer İçin Kurallar
Review Yaparken
- Review'a 24 saat içinde başla (blokaj yaratma)
- Kod mantığını anlamaya çalış, sadece syntax'a bakma
- Pozitif şeyleri de belirt: 'Güzel çözüm!' demek önemli
- Eleştiri kişiye değil koda yönelik olsun
- Soru sor: 'Neden böyle yaptın?' öğrenmek için
Yorum Tipleri
| Prefix | Anlamı | Örnek |
|---|---|---|
| [nit] | Ufak öneri, zorunlu değil | [nit] Burada const kullanabilirsin |
| [suggestion] | Alternatif yaklaşım | [suggestion] Early return daha okunur olabilir |
| [question] | Anlamak için soru | [question] Bu case'i neden handle etmiyoruz? |
| [blocker] | Merge öncesi düzeltilmeli | [blocker] Null check eksik, crash edebilir |
Review Odak Alanları
- Doğruluk: Kod istenen işi yapıyor mu?
- Tasarım: Mimari ve pattern'ler uygun mu?
- Okunabilirlik: Başka biri anlayabilir mi?
- Testler: Yeterli ve anlamlı test var mı?
- Güvenlik: Açık var mı? (injection, auth vb.)
- Performans: Gereksiz maliyet var mı?
- Dokümantasyon: Gerekli yorum/doc var mı?
Approval Kuralları
| Değişiklik Tipi | Minimum Approval | Not |
|---|---|---|
| Standart PR | 1 approve | Temel kural |
| Kritik sistem/DB | 2 approve | Sensitive değişiklikler |
| Hotfix (SEV1/2) | 1 approve + Tech Lead | Hızlı ama kontrollü |
| Refactoring (büyük) | 2 approve | Risk yüksek |
Antipattern'ler
- ❌ Rubber stamping: Gerçekten okumadan onay
- ❌ Bike shedding: Önemsiz detaylara takılma
- ❌ Geciktirme: Review'ları günlerce bekletme
- ❌ Ego: 'Ben olsam farklı yazardım' yaklaşımı
- ❌ Nitpick hell: Her satıra yorum yazma
- ❌ Context switching: Aynı PR'ı farklı reviewer'lar farklı yöne çekmeye çalışma
Anlaşmazlık Durumları
Yazar ve reviewer anlaşamadığında:
- 1. Offline görüşme: TodoTimeTracker/PR yorumları değil, kısa call
- 2. Tech Lead dahil et: Üçüncü görüş al
- 3. Disagree and commit: Karar alındığında ilerle
- 4. Öğrenme fırsatı: Tartışmayı dokümante et, pattern'e dönüştür
Code review kişisel bir saldırı değil, birlikte daha iyi kod yazmak için işbirliği. Ego kapıda kalır.