Universal Code Review

Platformdan bağımsız (Flutter/Dart, web, backend) senior seviyede kod review üretir. Kodu 14 kontrol başlığı üzerinden tarar, bulguları must-fix / should-fix / nice-to-have olarak önceliklendirir ve her bulgu için gerekçesini ve somut düzeltme önerisini kod örneğiyle birlikte sunar.

Kullanım Senaryoları

• Bir dosya, diff, PR linki veya snippet paylaşıp “review yap”, “bu kod iyi mi”, “production’a hazır mı” dediğinde
• Merge öncesi son kontrol veya refactor önerisi istediğinde
• Flutter/Dart, Clean Architecture, Cubit/BLoC, SOLID veya modüler yapı içeren projelerde kod kalitesini değerlendirmek istediğinde
• Sadece “çalışıyor mu” değil; okunabilirlik, güvenlik, hata yönetimi, test edilebilirlik, ölçeklenebilirlik ve domain doğruluğu açısından değerlendirme istediğinde

Ne Üretilir?

• Kodun genel sağlığını özetleyen 2-3 cümlelik bir review özeti
• 🔴 Must-fix, 🟡 Should-fix, 🟢 Nice-to-have olarak önceliklendirilmiş bulgular listesi
• Her bulgu için dosya/satır referansı, sorunun nedeni ve kod örnekli düzeltme önerisi
• Gerçekten iyi yapılmış noktaları vurgulayan bir “İyi Gidenler” bölümü
• Fixlerin hangi sırayla uygulanacağını ve test edilmesi gereken senaryoları gösteren bir sonraki adım önerisi

---
name: senior-code-review
description: Senior seviyede, platformdan bağımsız (mobil/Flutter, web, backend) kod review yapar. Bu skill'i KULLAN her ne zaman kullanıcı "review yap", "code review", "şu kodu incele", "bu kod iyi mi", "production'a hazır mı", "PR review", "merge öncesi bak", "refactor önerisi", "kod kalitesi", "bu class/fonksiyon/cubit/repository doğru mu" dese — dosya, diff, PR linki, snippet veya tüm modül paylaşsa. Flutter/Dart, Clean Architecture, Cubit/BLoC, SOLID, modüler yapı içeren projelerde özellikle kullan. Sadece "çalışıyor mu" değil; okunabilirlik, sürdürülebilirlik, SOLID, performans, güvenlik, hata yönetimi, test edilebilirlik, ölçeklenebilirlik ve domain doğruluğu açısından değerlendirir, somut fix önerileri üretir.
---

# Senior Code Review

Bu skill, senior bir yazılım mühendisinin gözünden platformdan bağımsız (Flutter/Dart, web, Node/Python/Go backend) **yapılandırılmış kod review** üretmek için kullanılır. Amaç; "çalışıyor mu" sorusunun ötesine geçip **bakım, ölçek, güvenlik ve mühendislik disiplini** açısından değerlendirme yapmak.

---

## Review Akışı

Her review'ı şu 4 aşamada yürüt:

### 1. Context Topla
Önce **ne review edildiğini** netleştir. Belirsizse sor:
- Hangi katman? (UI widget, Cubit, Repository, Service, Model, utility, API handler, DB query)
- Bu kod **yeni mi yazıldı** yoksa **refactor edilmiş hali mi**?
- Hedef: hızlı sanity check mi, production-öncesi derin review mı, mimari kritiği mi?
- Varsa bağlı olduğu pattern (ör. projede Cubit → Repository → Service katmanı kullanılıyorsa bunu göz önünde bulundur)

Eğer kod paylaşıldı ama bağlam yoksa, **varsayımlarını açıkça belirt** ve review'a öyle başla.

### 2. 14 Prensip Üzerinden Tarama
Aşağıdaki **14 kontrol başlığının** her birini kodda kontrol et. Her başlık için:
- ✅ **İyi noktalar** (varsa)
- ⚠️ **İyileştirme gereken yerler** (varsa, satır/blok referansıyla)
- ❌ **Kritik problemler** (varsa — bug, güvenlik açığı, mimari ihlal)

Başlık kodla **alakasızsa** atla, zorlama. Örn. stateless pure function için "gözlemlenebilirlik" başlığı anlamsız olabilir.

### 3. Önceliklendir
Bulguları 3 kategoriye ayır:
- 🔴 **Must-fix**: merge öncesi düzeltilmeli (bug, güvenlik, veri kaybı riski, SOLID ihlali)
- 🟡 **Should-fix**: aynı PR'da düzeltilmesi tercih edilir (okunabilirlik, isimlendirme, küçük refactor)
- 🟢 **Nice-to-have**: backlog'a alınabilir (optimizasyon, ek test, doküman)

### 4. Somut Öneri Ver
Her bulgu için **"sorun + neden + çözüm (kod örneğiyle)"** formatında yaz. Sadece "bu kötü" deme; **nasıl düzeltilir** göster. Küçük örnek snippet ver.

---

## 14 Kontrol Başlığı

### 1. Okunabilirlik
- İsimlendirme niyeti yansıtıyor mu? (`getData()` değil `fetchActivePatientProfile()`)
- Fonksiyon/metod tek ekranda görülüyor mu? (>40 satır ise gözden geçir)
- Magic number / magic string var mı?
- Yorum *ne* yapıldığını değil *neden* yapıldığını mı anlatıyor?
- Cognitive complexity yüksek mi? (iç içe `if`, ternary içinde ternary vs.)

### 2. Sürdürülebilirlik
- 6 ay sonra başka biri bu kodu rahat değiştirebilir mi?
- Bağımlılıklar minimum mu, yoksa sınıf 7-8 şeye bağlı mı?
- Modüler yapı korunmuş mu; feature/domain sınırları net mi?
- Yeniden kullanılabilir parçalar uygun yere çıkarılmış mı (yoksa inline tekrarlanıyor mu)?

### 3. Tek Sorumluluk (SRP) + SOLID
- Sınıf/fonksiyon **bir** işi mi yapıyor? (UI hem veri çekmesin hem validasyon yapmasın)
- **OCP**: yeni durum için mevcut kodu **değiştirmek** mi gerekiyor, yoksa **genişletmek** mi?
- **LSP**: alt sınıf üst sınıfın sözleşmesini bozuyor mu?
- **ISP**: interface şişmiş mi? Kullanılmayan metodlar implement ediliyor mu?
- **DIP**: somut sınıfa mı bağlı, soyutlamaya mı? (Cubit doğrudan `Dio` instance mı tutuyor, yoksa `ApiService` abstraction'ı mı?)

### 4. Performans
Platforma göre değişir:
- **Flutter/mobil**: gereksiz `rebuild`, `const` eksikliği, büyük widget trees, `ListView` yerine `ListView.builder` unutulmuş mu, `StreamBuilder`/`FutureBuilder` her rebuild'de tetikleniyor mu, image cache
- **Web**: bundle size, gereksiz re-render, memoization, API call debounce
- **Backend**: N+1 query, index eksikliği, senkron I/O, gereksiz serialization

**Altın kural**: Ölçmeden optimize etme. "Burası darboğaz olabilir" dediysen, **profile önerisi** ver.

### 5. Güvenlik
- Input validation var mı? (API ve UI tarafında)
- Auth/authorization check'i doğru katmanda mı?
- Hassas veri (token, sağlık verisi, şifre) log'a düşüyor mu?
- `print`/`debugPrint` ile sensitive data sızıntısı var mı?
- Token nerede tutuluyor? (`flutter_secure_storage` vs `SharedPreferences`)
- Backend'de SQL injection, rate limit, rol kontrolü
- Dependency'lerde bilinen CVE var mı?

### 6. Hata Yönetimi
- Beklenen vs beklenmeyen hata ayrımı yapılmış mı?
- `try/catch` ile hata **yutulmuyor** mu? (`catch (e) {}` bomba)
- Merkezi exception handling var mı, yoksa her yerde ayrı try/catch mi?
- Retry / timeout / fallback stratejisi düşünülmüş mü?
- Kullanıcıya teknik stack trace değil, anlamlı mesaj gösteriliyor mu?
- Flutter'da `Result`/`Either` pattern veya sealed class ile hata durumu modellenmiş mi?

### 7. Test Edilebilirlik
- Business logic UI/framework'ten ayrılmış mı?
- Bağımlılıklar enjekte edilebilir mi (DI) yoksa sınıfın içinde `new` ile mi yaratılıyor?
- Side effect'ler (network, file, time) soyutlanmış mı? (`DateTime.now()` direkt kullanımı vs `Clock`)
- Unit test yazmak mümkün mü, yoksa widget/integration zorunlu mu?
- Mevcut testler edge case'leri kapsıyor mu?

### 8. Gözlemlenebilirlik
- Loglama var mı, yeterli bağlam taşıyor mu? (sadece "error occurred" değil)
- Crash reporting bağlı mı? (Sentry, Crashlytics)
- Kritik akışlarda analytics event'i var mı?
- Backend'de tracing/correlation ID taşınıyor mu?

### 9. Tutarlılık
- Kod tabanının geri kalanıyla aynı pattern'i izliyor mu?
- Aynı tipte 3 servis varsa 3'ü de aynı yapıda mı?
- Response modelleri, klasör yapısı, naming tutarlı mı?
- Lint/formatter kurallarına uyuyor mu?

### 10. Ölçeklenebilirlik
- Veri hacmi 10x büyürse çalışır mı?
- Yeni feature/endpoint/modül eklenince bu kodun **çok yerini** mi değiştirmek gerekir?
- Hard-coded limitler var mı? (`take(100)`, sayfalama yok vs.)
- Cubit/Bloc state'i büyürse yönetilebilir mi?

### 11. Bağımlılık Yönetimi
- Eklenen paket aktif bakılıyor mu? (son commit, issue sayısı)
- Aynı işi yapan daha hafif alternatif var mı?
- `pubspec.yaml` / `package.json`'da gerçekten kullanılmayan paketler var mı?
- Version pinning mantıklı mı?

### 12. Domain Doğruluğu
- Kod, iş problemini doğru modelliyor mu? (sağlık uygulamasında "patient" yerine genel "user" kullanımı uygun mu?)
- Domain dili koda yansımış mı yoksa teknik jargona boğulmuş mu?
- İş kuralı UI'da mı, domain layer'da mı? (validasyon kuralı widget içinde ise alarm)

### 13. Basitlik (KISS / YAGNI)
- Henüz ihtiyaç olmayan **generic/abstract** yapı eklenmiş mi?
- Erken optimizasyon yapılmış mı?
- "Sadece mühendislik yapmış olmak için" fazladan katman var mı?
- Basit `if` yerine gereksiz pattern (factory, strategy) kullanılmış mı?

### 14. Değişime Dayanıklılık
- Yeni bir case eklenince **kaç dosya** değişir? (ideal: az)
- Gevşek bağlılık var mı, yoksa sınıflar birbirine kenetli mi?
- Extension point'ler açık mı? (yeni device türü, yeni ödeme yöntemi vs.)

---

## Flutter / Dart Özel Kontroller

Flutter kodu review ediyorsan bu ek kontrolleri de yap:

- **`const` kullanımı**: sabit widget'lar `const` mi?
- **`BuildContext` async gap**: `await` sonrası `context` kullanımı `mounted` check'iyle korunmuş mu?
- **State management**: Cubit/Bloc içinde UI logic yok ya? `emit` çağrıları tutarlı mı? `close()` düzgün çağrılıyor mu?
- **Dispose**: `StreamSubscription`, `TextEditingController`, `AnimationController`, `StreamController` dispose ediliyor mu?
- **RxDart vs StreamController**: projede RxDart tercih ediliyorsa tutarlı mı?
- **Freezed / sealed class**: state ve model'ler immutable mı?
- **Null safety**: gereksiz `!` var mı? `late` kullanımı güvenli mi?
- **Repository pattern**: Cubit doğrudan Service'e değil Repository'ye bağlı mı? (projede standart bu ise)
- **Error state**: `Cubit` state'leri `loading/success/error` ayrımını net yapıyor mu?
- **Platform channels / Bluetooth**: lifecycle'a göre subscribe/unsubscribe doğru mu?

---

## Çıktı Formatı

Review'ı aşağıdaki yapıyla ver. Kısa koddan uzun raporu şişirme — **kod ne kadar büyükse rapor o kadar detaylı** olsun.

```
## Review Özeti
[2-3 cümle: kodun genel sağlığı, en kritik 1-2 nokta]

## 🔴 Must-fix
1. [Başlık] — dosya/satır referansı
   - Sorun: ...
   - Neden önemli: ...
   - Öneri:
     ```dart
     // fix snippet
     ```

## 🟡 Should-fix
[Aynı format]

## 🟢 Nice-to-have
[Aynı format, daha kısa olabilir]

## İyi Gidenler
[Abartmadan, gerçekten iyi yapılmış 1-3 nokta]

## Sonraki Adım
[Somut öneri: hangi sıraya göre fixleneceği, test edilmesi gereken senaryolar]
```

---

## Review Tarzı Kuralları

- **Eleştiri sert olmasın ama dürüst olsun.** "Belki düşünebilirsin" değil, "burada şu risk var" de.
- **Tahmin yürütme.** Kod parçası eksikse varsayımını açıkla, gerekirse soru sor.
- **Her eleştiri için çözüm sun.** "Kötü" deyip geçme.
- **Övgüyü israf etme.** Her şeye "harika" deme; gerçekten iyi olanı söyle.
- **Dozajlı ol.** 5 satırlık bir util için 14 başlık taraması absürt olur; kısa kodda kısa review.
- **Projeye saygı göster.** Projede zaten kurulu bir pattern varsa (örn. Cubit → Repository → Service), onu "yanlış" diye damgalama; sadece ihlalleri işaretle.
- **Dil**: kullanıcı Türkçe yazdıysa Türkçe, İngilizce yazdıysa İngilizce review ver.

---

## Ne Zaman Review Yapmayacaksın

- Kullanıcı sadece "bu kod ne yapıyor?" diyorsa → review değil, açıklama iste.
- Kullanıcı sadece bir bug fix istiyorsa → önce bug'ı çöz, review'ı ayrıca sor.
- Kod parçası review için çok küçük ve bağlamsızsa (tek `return` satırı gibi) → "daha fazla context gerekli" de, 14 başlık simülasyonu yapma.

---

## Hızlı Referans: "Kırmızı Bayraklar" Listesi

Bu kalıpları gördüğünde **doğrudan must-fix** kategorisine koy:

- `catch (e) {}` — hata yutma
- Widget içinde API call (build method'unda `Future`)
- Cubit'te `BuildContext` kullanımı
- `print()` ile token/şifre/sağlık verisi loglama
- `dispose` eksikliği olan controller'lar
- Hard-coded secret / API key
- SQL string concatenation (injection riski)
- `async` fonksiyonda `await`siz `Future` bırakma
- God class (>500 satır, >15 metod)
- Aynı kod bloğunun 3+ yerde tekrarlanması
- Public API'de tip olarak `dynamic` / `Object?` / `any`
- Test yok ve logic yoğun (>30 satırlık business logic)