Code review teoride harika: ikinci göz bakıyor, bug erken yakalanıyor, knowledge sharing oluyor. Pratikte genelde iki kötü sonuçtan birine varıyor: 1) Review çok yavaş, 2-3 gün bekletiyor. 2) Review çok yüzeysel, “LGTM” ile geçiştirme.
Benim 10+ yıldır çeşitli takımlarda gördüğüm: bu ikisi arasında optimal bir yer var ama disciplin gerektiriyor. Bu yazıda pratik yaklaşımları paylaşacağım.
Review’un gerçek amacı
Amaç bug bulmak değil. CI/test suite bug bulmak için daha iyi. Code review için 3 asıl amaç:
1. Knowledge transfer. İkinci developer kod tabanının bu bölümünü öğreniyor. Bus factor azalıyor.
2. Design feedback. “Bu yaklaşım doğru mu?” sorusunu erkenden sorabilmek. Architecture decisions review’da tartışılıyor.
3. Consistency. Team’in code style, patterns, conventions sürüyor mu? Review bu discipline’ı koruyor.
Bug catching bonus. Ana amaç bu 3’ü.
PR size discipline
Büyük PR’lar iyi review alamıyor. 500+ satır değişiklik içeren PR’da reviewer’ın gözü yoruluyor, detaylı bakamıyor.
Benim kural: PR < 300 satır değişiklik (net, silinen hariç).
300+ satırsa:
– Gerçekten tek change mi? Bölünebilir mi?
– Tests ile birlikte mi gidiyor? Ayır.
– Refactor ve feature karışık mı? Ayır.
– Generated code var mı? .gitignore’de atılabilir mi?
500 satır üstü PR büyük warning. 1000+ satır genelde 2-3 PR’a bölünmeli.
Review için zaman ayırma
Calendar’da bloklar lazım. Yoksa review hep ertelenip 1-2 gün bekliyor.
Benim pattern:
– Sabah 10:00’da 30 dakika review slot
– Öğleden sonra 14:00’te 30 dakika review slot
Iki slot sayesinde PR sabah geliyorsa öğleden önce review alıyor, öğleden sonra geliyorsa aynı gün.
Takım’a expectation: PR açtıktan sonra 4 saat içinde first review, 24 saat içinde review tamamlanmış.
Review checklist
Subject’in ötesinde check edilmesi gerekenler:
Correctness:
– Bu kod gerçekten iddia ettiği şeyi yapıyor mu?
– Edge case’ler handle ediliyor mu?
– Null/empty/invalid input durumları?
Design:
– Abstraction doğru seviyede mi?
– Gerekli complexity mi yoksa over-engineering mi?
– Pattern mevcut kodla uyumlu mu?
Readability:
– Variable/function isimleri anlamlı mı?
– Yorum’lar gerekli yerlerde mi? (Kod kendi kendine açık olsun, yorum ancak “why” için)
– Fonksiyon uzunluğu makul mu?
Tests:
– Yeni feature’lar için test var mı?
– Test’ler aslında test edilmek isteneni test ediyor mu?
– Mock’lar gerçekçi mi?
Performance:
– N+1 query var mı?
– Gereksiz memory allocation?
– Database index kullanılıyor mu?
Security:
– SQL injection riski?
– XSS riski?
– Authorization check doğru yerde mi?
Hepsine her PR’da bakmak imkansız. Context’e göre odakla.
Review comment’ları yazma disiplini
Benim comment type’larım:
Blocking: Bu düzeltilmeden merge olamaz. Kritik bug, güvenlik, API kırıcı.
Suggestion: Düzeltmek iyi olur ama merge’e engel değil. Author karar veriyor.
Question: Anlamak için soru. Blocking değil, sadece clarification.
Praise: İyi yapılmış bir şey. Positive reinforcement önemli.
Her comment’i türünü prefix’le belirt:
[Blocking] Bu SQL query parameterized değil, injection riski var.
[Suggestion] Bu fonksiyon 50 satır, 2'ye bölmek daha clean olabilir.
[Question] `userId` negative olduğunda ne olur?
[Praise] Bu refactor teşekkürler, eski kod çok karmaşıktı.Author hangi comment’e mutlaka cevap vermesi gerektiğini biliyor. Review iteration’ları hızlanıyor.
Nit’ler vs important feedback
Nit = minor style/preference comment. “Bu değişken snake_case mi, camelCase mi olsun?” “Bu spacing hatalı.”
Nit’ler review’u yavaşlatıyor. Önerim: linter otomatik catchs’in.
ESLint, Prettier, SwiftFormat, RuboCop. Pre-commit hook veya CI check. Automated tooling style’ı enforce ediyor, review bunları tartışmıyor.
Style tartışması ekibin time’ını savunan bir şey değil. Tool’a outsource et.
Acknowledge vs change
Every review comment’e kod değiştirerek cevap vermek gerekmiyor.
Reviewer: “Bu değişken daha clear bir isim alabilir.”
Author opsiyonları:
1. Değiştir (“good point, renamed”)
2. Açıkla ve tutma nedenini söyle (“I kept this name because it matches the API naming in our legacy code”)
3. Thread’i kapat (mentioned, acknowledged, future work for now)
Her comment’e “fixed” ile cevap vermek review’un kalitesini düşürüyor. Gerçek conversation engaging. Sometimes reviewer wrong, sometimes author’s context haklı.
Async ve synchronous karışımı
Çoğu review async: PR açıl, comment’ler yazıl, author cevapla, iterate. Bu 1-2 güne yayılıyor.
Bazen synchronous daha verimli. Zoom call 15 dakika:
– Karmaşık review (architectural)
– Çok comment thread’i var
– Farklı görüşler var
Async yazışma 5 gün sürebilecek yerde synchronous 15 dakika bitiriyor.
Hibrid approach: async baseline, synchronous escalation option.
Pair programming vs review
Pair programming = synchronous live review. İki developer birlikte kod yazıyor.
Avantaj: instant feedback, no async delay. Dezavantaj: 2 developer’ın zamanı aynı iş için.
Karmaşık feature’lar, onboarding, knowledge transfer için pair programming. Daily iş için PR review.
Hibrid: büyük refactor pair programming’le yazılıyor, kendi içinde review edilmiş gidiyor. Sadece 1 fresh set of eyes review ediyor.
Junior ve senior review dinamikleri
Junior developer’ın PR’ını senior review ediyor: education opportunity. Detailed explanation, pattern teaching.
Senior developer’ın PR’ını junior review ediyor: tersi de değerli. Junior “bu kısmı anlamadım” demek yeni perspektif verir. Hem junior öğreniyor hem senior assumption’ları test ediyor.
Takım kültüründe bu bidirectional review olmalı. Senior’lar da review alıyor, top-down review yok.
Review metric’leri (tehlikeli ama useful)
Measurable things:
– PR review time (first comment’e kadar)
– PR total time (açılıştan merge’e)
– Review coverage (kaç reviewer, kaç comment)
– Comments per PR
Dikkat: Metric’ler davranış şekillendiriyor. “Comment count”u maximize etmek için saçma comment atmak başlayabilir.
Benim tercih: “review time” monitor, trend’e bak. 2 gün+ yavaşlama varsa uyarı. Absolute number’lar için target koymam.
Toxic review pattern’ları
Review’un kötüye gittiği sinyal’ler:
1. Nitpicking competition. Birçok reviewer her PR’a 20+ nit yazıyor, ego yarışı. Team culture problem.
2. “Why didn’t you do X” framing. Defensive positioning yaratıyor. “What if we did X?” daha collaborative.
3. Review’u gatekeeping olarak kullanma. Senior reviewer junior’ın her PR’ını reject ediyor. Power dynamics, productivity killer.
4. Bot-like approval. “LGTM” comment’i without gerçek inceleme. Review’un amacını yitiriyor.
5. Single approver bottleneck. Tek bir kişi tüm PR’ları review ediyor. Single point of failure, slow everyone down.
Bu pattern’ları retrospective’de open-ly tartışmak önemli. Sorun büyümeden fix.
Sonuç
Code review team velocity’sinin core’u. Yanlış yapıldığında bottleneck, doğru yapıldığında quality ve knowledge sharing sağlıyor.
PR size disciplin, allocated review time, structured comments, automated tooling for style. Bu 4 pillar’la hızlı ama derin review mümkün.
Sonra her takım için context’e göre fine-tune. Startup farklı, enterprise farklı. Ama temel prensipler evrensel: amaç “block” değil, “enable”.