Bir pull request açtınız. Üzerinde saatlerce çalıştığınız değişikliğe gelen ilk yorum şu:

“Bunu neden böyle yaptın?”

İncelemeyi yapan kişi tasarım kararını anlamak istiyor olabilir. Ancak yazılı iletişimde niyet görünmez; kelimeler görünür. Aynı soru, karşı tarafta merak yerine suçlanma hissi oluşturabilir.

Oysa kod incelemesinin amacı geliştiriciyi savunmaya zorlamak değil; hataları bulmak, tasarım kararlarını değerlendirmek ve bilgiyi ekip içinde paylaşmaktır.

Kod incelemesi kültürü, yorum yazarken seçtiğimiz kelimelerle ve bu kelimelerin arkasındaki gerekçelerle şekillenir. İyi bir inceleme, teknik beklentileri açık tutarken insanlara soru sorma, yanılma ve öğrenme alanı bırakır.

Kod incelemesi kültürü neden önemlidir?

Kod incelemesi, çoğu ekipte bir değişikliğin ana kod tabanına alınmasından önceki kontrol adımıdır. Ancak bu süreç yalnızca hata avına dönüştüğünde değerinin önemli bir bölümünü kaybeder.

Sağlıklı bir code review süreci üç iş yapar:

• Kaliteyi korur: Hataları, bakım maliyetini artıran kararları ve eksik senaryoları görünür kılar.
• Bilgiyi paylaşır: Bir modülün nasıl çalıştığını ve belirli kararların neden alındığını daha fazla kişinin anlamasını sağlar.
• Ortak standartları geliştirir: Ekibin okunabilirlik, test ve tasarım konusundaki beklentilerini somutlaştırır.

Bu kazanımlar, insanların incelemeye katılabildiği bir ortam gerektirir. Her yoruma karşı kendini savunmak zorunda hisseden bir geliştirici, zamanla sorularını ve tereddütlerini paylaşmaktan kaçınabilir.

Buradaki hedef eleştiriyi azaltmak değildir. Eleştiriyi daha açık, gerekçeli ve uygulanabilir hâle getirmektir.

Kişiyi değil, kodun davranışını değerlendirin

“Sen” dili, teknik bir problemi kolayca kişisel bir değerlendirmeye dönüştürür.

“Burada hata kontrolünü unutmuşsun.”

Bunun yerine kodun hangi durumda nasıl davranacağına odaklanabilirsini2z:

“Servis boş yanıt döndürdüğünde bu satır hata veriyor. Boş yanıt senaryosunu da ele alabilir miyiz?”

İkinci yorum, geliştiricinin dikkati veya yeterliliği hakkında çıkarım yapmaz. Sorunu, oluştuğu koşulu ve beklenen değişikliği belirtir.

Aynı yaklaşım tasarım yorumlarında da işe yarar:

“Bu fonksiyon çok kötü olmuş.”

yerine:

“Bu fonksiyon doğrulama, veri kaydetme ve bildirim gönderme işlerini birlikte yapıyor. Bildirim adımını ayırmak, bu davranışı bağımsız test etmeyi kolaylaştırabilir.”

Bu ifade hâlâ eleştireldir. Fakat karşı taraf artık neyi, neden değiştirmesi gerektiğini anlayabilir.

Yapıcı yorumun üç parçası: gözlem, etki ve öneri

Yorum yazarken kullanabileceğiniz pratik bir çerçeve vardır:

Gözlem → Etki → Öneri

Örneğin:

“Bu döngü her kullanıcı için ayrı bir veritabanı sorgusu çalıştırıyor. Kullanıcı sayısı arttığında sorgu sayısı da artacağı için yanıt süresi uzayabilir. İlgili kayıtları toplu çekmeyi değerlendirebilir miyiz?”

Bu yorumda:

• Gözlem: Her kullanıcı için ayrı sorgu çalışıyor.
• Etki: Veri büyüdükçe performans etkilenebilir.
• Öneri: Toplu sorgulama değerlendirilebilir.

Her yorumun üç uzun cümleden oluşması gerekmez. Küçük bir değişiklik için tek cümle yeterli olabilir:

“Bu değer saniye cinsinden olduğu için timeoutSeconds adı, çağrı noktalarında birim karışıklığını önleyebilir.”

Önemli olan, önerinin arkasındaki düşünceyi görünür kılmaktır. “Böylesi daha temiz” demek yerine temizliğin hangi somut faydayı sağladığını anlatın.

Zorunlu değişikliklerle tercihleri ayırın

Kod incelemelerinde sık yaşanan sorunlardan biri, bütün yorumların aynı ağırlıkta görünmesidir.

Bir yetkilendirme açığı ile değişken adı önerisi aynı biçimde yazıldığında, pull request sahibi hangi değişikliğin onay için gerekli olduğunu anlamakta zorlanır.

Basit bir etiketleme düzeni bu belirsizliği azaltabilir:

Yorum türü	Ne anlama gelir?	Örnek
Gerekli	Birleştirmeden önce çözülmesi gereken sorun	“Bu uç noktada yetki kontrolü eksik; eklenmesi gerekiyor.”
Öneri	Faydalı olabilecek, tartışmaya açık iyileştirme	“Bu dönüşümü ayrı bir fonksiyona almak okunabilirliği artırabilir.”
Soru	Bağlamı veya kararı anlamaya yönelik soru	“Burada önbelleği kullanmamamızın özel bir nedeni var mı?”
Küçük not	Birleştirmeyi engellemeyen ayrıntı	“Bu adı biraz daha açıklayıcı seçebiliriz.”
Olumlu geri bildirim	Korunmasını istediğiniz iyi yaklaşım	“Sınır durumlarını ayrı testlerle göstermen davranışı anlaşılır kılmış.”

Etiketlerin isimlerinden çok, ekipçe aynı anlamda kullanılması önemlidir.

Kişisel tercihinizi ekip standardı gibi sunmayın. Bir yaklaşım üzerinde anlaşılmış bir kurala dayanıyorsa ilgili kuralı paylaşın. Tercihinizse bunu açıkça belirtin.

Soru sormak her zaman nazik olmak değildir

Bazı yorumlar soru biçiminde yazılsa da suçlayıcı bir mesaj taşır:

“Bunun çalışacağını gerçekten düşünüyor musun?”

Bu cümle teknik bir açıklama istemekten çok, kişinin karar verme becerisini sorgular.

Gerçek bir soru, bilinmeyen noktayı belirtir:

“İki istek aynı anda geldiğinde aynı kaydın iki kez oluşturulmasını hangi mekanizma engelliyor?”

Burada soru hem somuttur hem de incelenebilir bir davranışa yönelir.

Öte yandan, kesin olarak tespit ettiğiniz bir hatayı gereksiz yere belirsizleştirmeniz de gerekmez:

“Belki burada bir kontrol eklemeyi düşünebilir miyiz acaba?”

yerine:

“Liste boş geldiğinde ilk elemana erişim hata veriyor. Birleştirmeden önce boş liste durumunu ele almamız gerekiyor.”

Saygılı iletişim, beklentilerin belirsiz olması anlamına gelmez.

Yorumun kapsamını değişikliğin amacıyla sınırlayın

Küçük bir hata düzeltmesini incelerken bütün modülün yeniden tasarlanmasını istemek, çalışmanın kapsamını büyütür.

Bir sorun gördüğünüzde şu ayrımı yapın:

• Bu değişiklik sorunu oluşturuyor veya ağırlaştırıyor mu?
• Sorun, değişikliğin doğru ve güvenli çalışmasını engelliyor mu?
• İyileştirme ayrı bir çalışma olarak ele alınabilir mi?

Örneğin:

“Bu sınıfta daha geniş bir sadeleştirme fırsatı var. Mevcut hata düzeltmesini engellemiyor; ayrı bir iş olarak takip edebiliriz.”

Bu yaklaşım teknik borcu görmezden gelmez. Acil düzeltme ile kapsamlı iyileştirmenin önceliğini ayırır.

Bununla birlikte, değişiklik mevcut bir riski doğrudan tetikliyorsa sorunu yalnızca “önceden de vardı” diyerek ertelemek doğru değildir. Kararı, kodun yaşı yerine değişikliğin etkisine göre verin.

Olumlu geri bildirimi de somutlaştırın

Kod incelemelerinde yalnızca değişmesi gereken yerler konuşulduğunda, iyi kararlar görünmez kalır.

“Güzel olmuş” demek olumlu bir jesttir. Ancak hangi yaklaşımın değerli olduğunu anlatmak daha öğreticidir:

“Tarih bilgisini dışarıdan vermen, testlerin sistem saatine bağımlı olmasını önlemiş.”

Ya da:

“Hata mesajına işlem kimliğini eklemen, üretimde sorun takibini kolaylaştıracak.”

Somut olumlu geri bildirim, ekibin hangi uygulamaları sürdürmek istediğini gösterir. Her eleştirinin yanına zorunlu bir övgü eklemeniz gerekmez; gördüğünüz iyi kararları gerekçesiyle belirtmeniz yeterlidir.

Anlaşmazlık uzadığında iletişim biçimini değiştirin

Yorum dizisi uzuyor, aynı gerekçeler tekrarlanıyor ve konu giderek daha zor anlaşılıyorsa kısa bir görüşme faydalı olabilir.

Görüşmede önce ortak hedefi netleştirin: Okunabilirliği mi, performansı mı, değişiklik kapsamını mı korumaya çalışıyorsunuz? Ardından seçenekleri bu hedef üzerinden karşılaştırın.

Kararı pull request üzerinde özetlemeyi unutmayın:

“Görüştük: Mevcut veri hacmi ve değişikliğin kapsamı nedeniyle bu yaklaşımı koruyoruz. Daha büyük veri kümeleri için toplu sorgulamayı ayrı bir işte değerlendireceğiz.”

Böylece kararın gerekçesi, görüşmeye katılmayan kişiler için de erişilebilir olur.

Yorum göndermeden önce kısa kontrol listesi

Bir yorumu yayınlamadan önce şu soruları sorun:

• Sorunu belirli bir davranış veya senaryoyla açıklıyor muyum?
• Neden önemli olduğunu belirtiyor muyum?
• Değişikliğin gerekli mi, isteğe bağlı mı olduğu anlaşılıyor mu?
• Eksik bağlamım olabileceğini hesaba katıyor muyum?
• Kişi hakkında çıkarım yapmak yerine kodu değerlendiriyor muyum?
• Bu ayrıntı otomatik bir biçimlendirme veya analiz aracıyla kontrol edilebilir mi?

Biçimlendirme gibi tekrar eden kontrolleri mümkün olduğunda araçlara bırakmak, insanların tasarım, doğruluk ve bakım kolaylığı üzerine konuşmasına alan açar.

İyi bir inceleme, bir sonraki değişikliği de iyileştirir

Başarılı bir kod incelemesi, mevcut pull request’in düzelmesiyle sınırlı kalmaz. Geliştiricinin bir sonraki değişiklikte daha bilinçli kararlar vermesine de yardımcı olur.

Bunun için yorumun yalnızca ne yapılacağını değil, neden yapılacağını da anlatması gerekir. Gerekçesiz talimat işi kapatabilir; anlaşılır bir açıklama bilgiyi paylaşır.

Bir sonraki incelemenizde tek bir alışkanlığı deneyin: İstediğiniz değişikliğin yanına, o değişikliğin hangi sorunu çözdüğünü ekleyin. Kod incelemesi kültürünü güçlendiren şey, günlük yorumlarda tekrar edilen bu tür somut davranışlardır.