Kod review, çoğu ekipte yanlış anlaşılan küçük bir ritüeldir: Bir geliştirici kodunu açar, diğerleri büyüteçle kusur arar, sonra yorumlar yağar. Fakat iyi bir kod review, dijital bir mahkeme değil; ortak aklın laboratuvarıdır. Burada amaç, birinin hatasını yakalayıp zafer turu atmak değil, henüz üretime çıkmamış bir fikrin nerede tökezlediğini birlikte görmektir. Çünkü kod, sadece makineye verilen talimat değildir; yazanın zihinsel modelinin donmuş hâlidir.
Bir fonksiyona baktığınızda aslında şunu sorarsınız: Bu insan problemi nasıl anlamış? Hangi varsayımlarla ilerlemiş? Hangi olasılıkları görmüş, hangilerini karanlıkta bırakmış? İşte eleştirel düşünme burada devreye girer. Eleştirel düşünme, sert konuşmak değildir. Tam tersine, aceleci yargıyı askıya alıp mantık zincirini tek tek izleme disiplinidir. Kod review yapan kişi, biraz dedektif, biraz editör, biraz da iyi niyetli bir satranç rakibidir.
Hata değil, varsayım avla
Yeni başlayan reviewer’ların çoğu yüzeyde kalır: Değişken adı kötü, satır fazla uzun, burada noktalı virgül eksik. Bunlar önemlidir ama asıl mesele genellikle daha derindedir. Bir ödeme sistemi düşünün. Kod düzgün çalışıyor gibi görünür; testler yeşildir. Fakat geliştirici, aynı kullanıcının aynı anda iki kez ödeme isteği göndermeyeceğini varsaymıştır. İşte bu, mantık hatasının altın madenidir. Kod review’un ustalığı, yazılmamış cümleleri duymaktır: “Bu değer asla null olmaz.” “Bu servis hep cevap verir.” “Kullanıcı bunu yapmaz.” Yazılım tarihinin mezarlığı, bu cümlelerin enkazıyla doludur.
Yapıcı eleştiri için ilk kural şudur: Kişiye değil, modele saldır. “Bunu yanlış yapmışsın” demek savunma mekanizmasını çağırır. “Bu senaryoda aynı kayıt iki kez oluşabilir mi?” demek ise düşünceyi davet eder. İyi soru, kötü yorumdan daha keskindir. Çünkü soru, sahibini utandırmadan zihinsel süreci yeniden çalıştırır. Kod review’da en etkili cümleler çoğu zaman emir kipinde değil, keşif kipindedir: “Burada race condition ihtimali var mı?”, “Bu kontrol daha yukarıda yapılsa akış sadeleşir mi?”, “Bu fonksiyon iki sorumluluk taşıyor olabilir mi?”
Eleştirinin ergonomisi
Bir yorumun teknik olarak doğru olması yetmez; kullanılabilir olması gerekir. “Bu kötü” gibi bir yorum, harita değil sis üretir. İyi bir review yorumu üç parçadan oluşur: gözlem, gerekçe, öneri. Örneğin: “Bu döngü içinde veritabanına her seferinde sorgu atılıyor; büyük listelerde performans problemi oluşturabilir; toplu sorgu veya önbellekleme daha güvenli olabilir.” Bu cümle hem problemi gösterir hem nedenini açıklar hem de çıkış kapısı bırakır. Eleştiri, kapıyı kilitlemek değil, menteşeyi yağlamaktır.
Elbette reviewer da hatalı olabilir. Hatta sık sık olur. Bu yüzden kesinlik sarhoşluğuna kapılmamak gerekir. Kod review, “ben bilirim” arenası değil, “beraber daha az yanılırız” yöntemidir. Bir öneri sunduğunuzda onun bağlama uyup uymadığını kontrol edin. Belki o çirkin görünen kod, eski bir sistemin zorunlu uyumluluğu yüzündendir. Belki tekrar gibi görünen parça, bilinçli olarak ayrılmıştır. Eleştirel düşünmenin olgun hâli, kendi eleştirisini de inceleyebilmektir.
İyi review kültürü nasıl kokar?
İyi bir ekipte review yorumları kişisel itibar savaşına dönüşmez. Junior geliştirici soru sorabilir, senior geliştirici fikrini değiştirebilir. “Neden böyle yaptın?” cümlesi sorgu odası tonuyla değil, merakla söylenir. Bir PR’da sadece kusur değil, iyi kararlar da işaretlenir: “Bu ayrım okunabilirliği artırmış”, “Bu test kenar durumu güzel yakalamış.” Çünkü beyin yalnızca ceza ile değil, tanınma ile de öğrenir.
Sonuçta kod review, yazılım kalitesinden daha fazlasını üretir: Ortak düşünme kası üretir. Başkasının mantık hatasını yapıcı biçimde bulmak, kendi kör noktalarımızı da eğitir. Her review’da şu küçük ahlaki seçim yapılır: Haklı çıkmak mı istiyorum, yoksa sistemi daha doğru hâle getirmek mi? İlki egoyu besler, ikincisi ürünü. İyi reviewer, hatayı yakalayan kişi değil; hatanın ortaya çıkabileceği düşünme ortamını kuran kişidir. Ve bazen en iyi review yorumu, sadece şu sorudur: “Burada neyi doğru kabul ediyoruz?”