Aşağıdaki ekip için kod review süreci tasarla:
EKİP:
- Büyüklük: [N GELİŞTİRİCİ]
- Dil: [PYTHON / JS / JAVA / GO / DİĞER]
- Mevcut süreç: [YOK / İNFORMAL / VAR AMA YAVAŞ]
ÜRET:
1. PR (PULL REQUEST) ŞABLONU:
```
## Ne değişti?
[1-2 cümle özet]
## Neden?
[Motivasyon, ticket/issue link]
## Nasıl test ettim?
[Manuel test, unit test, integration test]
## Ekran görüntüsü (UI değişikliği varsa)
## Checklist
- [ ] Testler geçiyor
- [ ] Linting temiz
- [ ] Dökümantasyon güncellendi
- [ ] Breaking change var mı? Açıkla
```
2. REVIEW CHECKLIST:
DOĞRULUK:
- İş gereksinimini karşılıyor mu
- Edge case'ler düşünülmüş mü
- Hata yönetimi (try-catch, error handling)
- Null/undefined kontrolü
OKUNABİLİRLİK:
- İsimlendirme anlaşılır mı (değişken, fonksiyon, sınıf)
- Fonksiyon uzunluğu (<30 satır ideal)
- Yorum: neden yazıyor (ne yaptığı koddan belli olmalı)
- DRY: tekrarlanan kod var mı
PERFORMANS:
- N+1 sorgu
- Gereksiz döngü / O(n²) uyarısı
- Bellek sızıntısı riski
- Cache kullanılabilir mi
GÜVENLİK:
- SQL injection, XSS, CSRF
- Input validation
- Secret/credential kodda mı (hayır olmalı)
- Yetki kontrolü
TEST:
- Unit test yazılmış mı
- Coverage düşmüş mü
- Happy path + error path
3. GERİ BİLDİRİM TONU:
- Soru sor ("Bu yaklaşımı X için mi seçtin?") emretme değil
- Nit: (nitpick) — küçük, opsiyonel
- Suggestion: — öneriyorum ama zorunlu değil
- Blocker: — bu düzelmeden merge edemem
- Övgü ver ("Bu çözüm çok elegant!")
4. SÜREÇ:
- PR boyutu: <400 satır ideal (büyükse böl)
- Review süresi: 24 saat içinde ilk yanıt
- Approval: min 1 (kritik: 2)
- Merge: squash merge + anlamlı commit message
5. OTOMASYON:
- Linter (ESLint, Pylint, golangci-lint)
- Formatter (Prettier, Black, gofmt)
- CI testleri (PR açılınca otomatik)
- Coverage raporu (Codecov)
- SAST güvenlik tarama (SonarQube, Snyk)
Türkçe, modern yazılım mühendisliği code review best practice.