Kod incelemesinin gerçekten işe yarayan hâli

Kod incelemesi (code review) çoğu ekipte iki uçtan birine düşüyor: ya boşluk ve isimlendirme tartışmasına dönüşüyor, ya da "LGTM" yazıp geçilen bir formaliteye. İkisi de zaman harcıyor, ikisi de hata yakalamıyor.

İncelemenin faydalı olduğu ekiplerde ortak olan beş şey var.

1. Makinenin bakabileceği şeye insan bakmıyor

Biçimlendirme, sıralama, kullanılmayan değişken, basit tip hataları — bunların hepsi otomatik araçların işi. İnceleme sırasında bunlar konuşuluyorsa, ekip zamanını bir programın yerine geçerek harcıyor.

İlk yatırım: biçimlendirici (formatter) + statik analiz, ikisi de dağıtım hattında zorunlu. Bu kurulduktan sonra incelemede kalan şey gerçekten insan yargısı gerektiren kısım oluyor.

2. Değişiklik küçük

400 satırlık bir değişiklik gerçekten incelenmiyor; göz geziliyor. Bu, üzerinde tartışılacak bir konu değil, gözlemlenmiş bir davranış: değişiklik büyüdükçe tespit edilen sorun sayısı artmıyor, düşüyor.

Pratik hedef: tek bir amaca hizmet eden, 200 satırın altında değişiklikler. Büyük iş, birden çok küçük değişikliğe bölünmeli — ve bölünemiyorsa bu genelde tasarımın kendisiyle ilgili bir işaret.

3. Yazan, ne aradığını söylüyor

İnceleme isteğinin açıklaması "şu özelliği ekledim" ise, inceleyen nereye bakacağını bilmiyor. Faydalı açıklama şunu içerir:

• Ne değişti ve neden (bağlantılı görev değil, bir cümle)
• Nasıl test edildi
• Emin olmadığım yer — en değerli satır bu

Son maddeyi yazmak zor geliyor ama incelemenin verimini en çok artıran şey o. "Şu kilitlenme senaryosundan emin değilim" cümlesi, inceleyenin dikkatini doğru yere yönlendiriyor.

4. Yorumlar sınıflandırılıyor

Her yorum aynı ağırlıkta değil ama okuyan bunu anlayamıyor. Basit bir ön ek sistemi bu sorunu tamamen çözüyor:

• engel: Bu düzeltilmeden birleştirilmemeli.
• öneri: Bence daha iyi olur, ama karar sende.
• soru: Anlamadım, açıklar mısın.
• not: Bilgi amaçlı, aksiyon gerekmiyor.

Bu dört ön ek, incelemedeki gerginliğin büyük kısmını ortadan kaldırıyor. Çünkü gerginlik genelde bir "öneri"nin "engel" gibi okunmasından çıkıyor.

5. İnceleme, mimariyi tartışma yeri değil

Bir değişiklik incelemesinde "bu yaklaşım yanlış, baştan yazmalıyız" demek, iş bittikten sonra söylenmiş bir şey. Bu noktada söylenmesi, hem yazanı hem işi yakıyor.

Mimari tartışması işten önce yapılmalı: kısa bir tasarım notu, bir çizim, on dakikalık bir konuşma. Bu adım atlandığında inceleme, tasarım tartışmasının gecikmiş ve pahalı hâline dönüşüyor.

Neye bakmalı

İnceleme sırasında gerçekten değer üreten sorular:

• Bu kod hata durumunda ne yapıyor? Mutlu yol zaten test edilmiş oluyor; asıl risk diğerinde.
• Bu değişiklik geri alınabilir mi? Veri göçü içeriyorsa, geri alma planı var mı?
• Sınır durumlar: boş liste, tek eleman, çok büyük girdi, eş zamanlı iki istek.
• Bu isim altı ay sonra doğru mu olacak? İsimlendirme biçim değil, anlam meselesi — ve bu insan işi.
• Test, davranışı mı yoksa uygulamayı mı test ediyor? Uygulamayı test eden testler, ilk yeniden düzenlemede çöpe gidiyor.

Süre kuralı

İnceleme bekleyen bir değişiklik, ekibin akışını durdurur. Makul bir kural: bir iş günü içinde ilk yanıt. Yanıt "inceledim" olmak zorunda değil; "yarın sabah bakacağım" da bir yanıttır ve yazanın planlamasını sağlar.

Bunu kural hâline getirmek, incelemenin kalitesini bekleme süresini kısaltmaktan daha çok artırıyor — çünkü bekleyen değişiklikler büyüyor, birleşiyor ve incelenemez hâle geliyor.

İki kişilik ekiplerde

Küçük ekiplerde inceleme genelde "zaten ikimiz de her şeyi biliyoruz" diye atlanıyor. Buradaki risk kalite değil, tek nokta bilgisi. İki kişilik bir ekipte incelemenin asıl işlevi hata bulmak değil, kodun ikinci bir kişi tarafından okunmuş olması.

O yüzden küçük ekiplerde inceleme daha hafif ama yine de yapılmalı: 5 dakikalık bir göz gezdirme, altı ay sonra "buraya ben hiç bakmamıştım" cümlesini önlüyor.