Pek çok yazılımcı için Code Review (CR), kodun içindeki bug'ları cımbızla çekme seansıdır. Oysa CR süreci teknik bir check-list'ten ziyade, bireysel egoların törpülendiği, kolektif aklın devreye girdiği bir kültür inşasıdır. Bu yazıda, CR'ın neden "hata avcılığı" değil, bir "perspektif genişletme" aracı olduğunu inceliyoruz.
Yazılım dünyasında en çok yanlış anlaşılan süreçlerden biri Code Review (Kod İnceleme) seanslarıdır. Junior seviyede bu süreç bir "sorgulama" gibi hissedilir; Senior seviyede ise bazen bir "otorite kurma" aracına dönüşebilir. Ancak her iki uç nokta da CR'ın gerçek amacını ıskalar.
Code Review'un asıl amacı hata bulmak değildir. Hataları bulmak için unit testleriniz, linter'larınız ve otomatize QA süreçleriniz olmalı. CR’ın asıl amacı; egoyu devre dışı bırakıp, projeyi "benim kodum" seviyesinden "bizim kodumuz" seviyesine taşımaktır.
Bir yazılımcı için kodu, onun sanatıdır. Gece gündüz uğraştığınız bir çözümün altına birinin gelip "Neden böyle yaptın?" yazması, savunma mekanizmalarını (fight-or-flight) tetikler.
Ancak mühendislik, duygularla değil verilerle ve sürdürülebilirlikle yürür. Code Review süreci, yazılımcıya şu gerçeği her gün hatırlatır: Sen, yazdığın kod değilsin. Kodun eleştirilmesi, senin yeteneğinin eleştirilmesi değil, çözümün optimize edilmesidir. Bu farkındalık, egonun kırıldığı ve gerçek gelişimin başladığı yerdir.
CR seanslarında en çok duyulan savunma cümlesi: "Ama kod çalışıyor!" Lazy Ant perspektifinden bakarsak; bir kodun çalışması, onun production'a çıkmaya hazır olduğu anlamına gelmez. CR şu soruların peşine düşer:
Bu kodu 6 ay sonra ben (veya bir başkası) okuduğunda anlayacak mı?
Bu çözüm, projenin genel mimari tutarlılığına uyuyor mu?
Yarın gereksinimler değiştiğinde bu kod kolayca esneyebilecek mi?
İyi bir ekipte Pull Request (PR) alanı, bir okul gibidir. Sadece kodu yazan değil, inceleyen de öğrenir.
Yorum yapan: "Bunu şu yeni kütüphane/metod ile daha performanslı yapabileceğini biliyor muydun?" diyerek bilgi aktarır.
Kodu yazan: Farklı bir bakış açısıyla tanışır ve kendi "blind spot" (kör nokta) alanlarını keşfeder.
Bu etkileşim, ekibin "Bus Factor" (bir kişinin projeden ayrılması durumunda oluşacak risk) oranını düşürür. Bilgi tek bir beyinde hapsolmaz, yayılır.
Eğer CR süreci ekibinizde bir gerginlik kaynağıysa, şu kuralları devreye almanın vakti gelmiştir:
Kişiselleştirmeyin: "Sen böyle yapmışsın" yerine "Bu fonksiyon şöyle olsa daha iyi olmaz mı?" gibi nesne odaklı konuşun.
Nedenini Açıklayın: "Bunu değiştir" demek yerine, "Bunu değiştirirsek şu sebepten dolayı daha performanslı olur" diyerek eğitin.
Övgüyü Unutmayın: Sadece eksikleri değil, iyi yazılmış kısımları da belirtin. "Harika bir yaklaşım, bunu daha önce düşünmemiştim" demek egoları eritir, güveni artırır.
Teknik borç (technical debt) sadece yanlış yazılan kodlarla değil, paylaşılmayan bilgi ve sorgulanmayan kararlarla da büyür. Code Review, bu borcun en büyük düşmanıdır.
Bir yazılımcının "Senior" ünvanını hak etmesi, sadece en karmaşık algoritmayı yazmasıyla değil; PR yorumlarına verilen cevaplardaki olgunluğu ve başkasının koduna kattığı değerle ölçülür. Unutmayın; en iyi kod, herkesin üzerinde anlaştığı ve herkesin sahiplendiği koddur.
