Code Review'u Angarya Olmaktan Çıkarmak: Pratik Bir Rehber

Code review, çoğu ekipte ya gecikmenin bahanesi ya da üstünkörü bir "LGTM" ritüelidir. Oysa doğru işletildiğinde, bir ekibin sahip olabileceği en ucuz kalite ve öğrenme aracıdır: hata daha üretime çıkmadan yakalanır, bilgi ekipte yayılır, kod tabanı ortak bir dile kavuşur. Farklı ölçeklerde ekiplerde hem review veren hem alan biri olarak damıttığım ilkeler şunlar.

İdeal akış — otomatik kontroller önde, insan zamanı asıl işe:

Review veren için

Önce niyeti anla, sonra satırları

İlk okuma ne değişiyor ve neden sorusuna cevap aramalı; satır satır inceleme ondan sonra gelir. PR açıklaması bu soruya cevap vermiyorsa, ilk yorum satır eleştirisi değil, "bu değişikliğin amacını açıklar mısın?" olmalı.

Kademeli önem: her yorum eşit değildir

• Engelleyici: Hata, veri kaybı riski, güvenlik açığı, geri alınamaz API kararı.
• Öneri: Daha iyi bir yol var ama mevcut hali de çalışır.
• Nit: İsimlendirme, üslup. Başına nit: yazın ki yazar öncelik sırasını bilsin.

Bu ayrımı yapmayan reviewer, on tane üslup yorumunun arasında tek kritik hatayı görünmez kılar.

Koda konuş, kişiye değil

"Burada null kontrolü eksik, şu girdiyle NPE alırız" ile "yine null kontrolünü unutmuşsun" arasındaki fark, ekibin psikolojik güvenliğidir. İyi review kültürü olan ekipte insanlar hatalarını saklamaz; hatalar erken görünür olur.

Review alan için

Küçük PR, hızlı review

Review kalitesi, PR boyutuyla ters orantılıdır. 400 satırlık bir değişiklik özenle incelenir; 4000 satırlık değişiklik onaylanır. Büyük işi mantıksal adımlara bölmek yazarın sorumluluğudur — refactor ayrı, davranış değişikliği ayrı commit/PR.

Reviewer'ın zamanına saygı

PR'ı açmadan önce kendi diff'inizi bir kez kendiniz review edin. Unutulmuş debug satırları, alakasız format değişiklikleri, yarım kalmış TODO'lar reviewer'ın enerjisini asıl işten çalar.

Yoruma savunmayla değil, merakla yaklaş

Her review yorumu iki şeyden birini üretir: ya kod düzelir ya da yazar, kararının gerekçesini yazılı hale getirir. İkisi de kazançtır. "Haklısın, düzeltiyorum" kadar "şu sebeple bilinçli böyle yaptım, yoruma ekleyeyim mi?" da sağlıklı bir cevaptır.

Ekip için: sistemi kur, iradeye bel bağlama

• Otomatikleştirilebilen her şey otomatik olmalı. Format, lint, temel statik analiz CI'da koşar; insan zamanı tasarıma ve mantığa harcanır. İnsanın format tartıştığı her dakika, mantık hatasının gözden kaçtığı bir dakikadır.
• Review SLA'sı belirleyin. "24 saat içinde ilk bakış" gibi basit bir kural, PR'ların günlerce beklemesini engeller.
• Review yükünü paylaştırın. Tek 'gatekeeper' hem darboğazdır hem de bilginin tek kişide birikmesi demektir.

Yapay zekâ çağında review

Kod üretiminin hızlandığı, satır yazmanın ucuzladığı bu dönemde denklem değişti: darboğaz artık kodu yazmak değil, doğrulamak. Üretilen kod hacmi büyüdükçe, "bu değişiklik gerçekten doğru mu, gereksiz karmaşıklık getiriyor mu, mevcut mimariyle uyumlu mu" sorularını soran insan review'unun değeri düşmüyor — tam tersine yükseliyor. Review becerisi, önümüzdeki dönemin en kritik mühendislik becerilerinden biri.

---

Code review'un asıl çıktısı onaylanmış bir PR değil; zamanla birbirinin kodunu okuyabilen, aynı kalite çıtasını paylaşan bir ekiptir.