Kod incelemesi (code review) nasıl yapılır? Ekibi yormadan kaliteyi artırmak

Kod incelemesi, bir geliştiricinin yaptığı değişikliğin ana dala birleştirilmeden önce başka bir geliştirici tarafından okunmasıdır. İyi yapıldığında hataları canlı ortama çıkmadan yakalar, bilgiyi ekip içinde yayar ve kodun tutarlı kalmasını sağlar. Kötü yapıldığında ise ya hiçbir şey yakalamayan bir formaliteye ya da ekibi yoran bir sürtüşme kaynağına dönüşür.

İnceleyenin önceliği

İncelemede her şeye aynı ağırlıkla bakmak, önemli olanın gözden kaçmasına yol açar. Önem sırasına göre:

1. Doğruluk

Kod söylediği işi yapıyor mu? Kenar durumlar düşünülmüş mü? Boş liste, sıfır, negatif sayı, null, çok uzun metin, Türkçe karakterler, eşzamanlı istekler... Hataların büyük kısmı bu kenarlarda saklanır.

2. Güvenlik

Kullanıcıdan gelen veri doğrulanıyor mu? SQL sorguları parametreli mi? Çıktılar kaçırılıyor mu? Yetki kontrolü yapılıyor mu? Örneğin /fatura/123 adresine giren kullanıcının o faturanın sahibi olup olmadığı kontrol ediliyor mu? Loglara şifre ya da kişisel veri yazılıyor mu?

3. Veri ve geriye dönük uyumluluk

Veritabanı değişikliği varsa: Büyük bir tabloyu kilitler mi? Geri alınabilir mi? Mevcut veriler ne olacak? API'de bir alan değişiyorsa, onu kullanan istemciler bozulur mu?

4. Okunabilirlik ve tasarım

Altı ay sonra bu kodu okuyan biri ne yaptığını anlayabilir mi? Fonksiyon ve değişken adları amacı anlatıyor mu? Aynı iş başka bir yerde zaten yapılmış mı? Değişiklik, projenin geri kalanındaki kalıplarla tutarlı mı?

5. Testler

Yeni davranış için test var mı? Düzeltilen hata için o hatayı yeniden üreten bir test eklenmiş mi?

6. Biçim ve stil

Girinti, boşluklar, tırnak türü, satır uzunluğu... Bunlar insanların değil, araçların işidir. Bir kod biçimlendirici (PHP-CS-Fixer, Prettier, Black) ve linter'ı CI sürecine ekleyin. İncelemede biçim tartışmak, hem zaman kaybıdır hem de daha önemli konuların gözden kaçmasına yol açar.

Nasıl yorum yazılır?

İnceleme kodla ilgilidir, kişiyle değil. Yorumun tonu, söylenen şey kadar önemlidir.

Soru sorun, emir vermeyin:

Kötü: Bu yanlış, düzelt.
İyi:  Liste boş geldiğinde $urunler[0] hata vermez mi? Bir kontrol eklesek mi?

Nedenini açıklayın:

Kötü: Burada prepared statement kullan.
İyi:  $arama doğrudan sorguya ekleniyor; kullanıcıdan geldiği için SQL injection'a açık.
      PDO ile parametre olarak verebilir miyiz?

Önemini belirtin. Her yorum aynı ağırlıkta değildir. Önemsiz önerileri işaretleyin ki yazar neyin zorunlu olduğunu bilsin:

[engelleyici] Yetki kontrolü eksik; başka kullanıcının siparişi görüntülenebiliyor.
[öneri]       Bu döngü array_map ile daha kısa olabilir, ama böyle de olur.
[soru]        Bu sabit neden 37? Bir yorum satırı ekleyebilir miyiz?

İyi olanı da söyleyin. "Bu kısmı çok temiz çözmüşsün" demek, incelemenin yalnızca hata aramaktan ibaret olmadığını gösterir ve ekipte güveni artırır.

Uzayan tartışmayı yazıdan çıkarın. Bir yorumun altında üçüncü kez karşılıklı mesaj yazılıyorsa, beş dakikalık bir görüşme çok daha verimlidir. Sonucu yine incelemeye not olarak ekleyin.

Değişikliği hazırlayan için

İyi bir inceleme, iyi hazırlanmış bir değişiklikle başlar.

Küçük tutun. 2.000 satırlık bir değişiklik gerçekten incelenmez; yalnızca göz gezdirilir. Araştırmalar ve deneyim, birkaç yüz satırın üzerindeki değişikliklerde inceleme kalitesinin hızla düştüğünü gösteriyor. Büyük bir işi mantıklı parçalara bölün: önce yeniden düzenleme (refactoring), sonra yeni özellik.

Açıklama yazın. Değişiklik ne yapıyor, neden yapılıyor, nasıl test edildi? Ekran değişikliği varsa bir ekran görüntüsü ekleyin. İnceleyenin bağlamı koddan tahmin etmesini beklemeyin.

Önce kendiniz inceleyin. Göndermeden önce farkı (diff) baştan sona kendiniz okuyun. Unutulmuş hata ayıklama satırları, yorum satırına alınmış kod blokları ve ilgisiz dosya değişiklikleri çoğu zaman bu aşamada yakalanır.

Yorumları kişisel almayın. Kodunuz hakkında yapılan bir yorum, sizin hakkınızda değildir. Katılmıyorsanız nedenini açıklayın. İnceleyen de yanılabilir.

Hız da önemli

Günlerce bekleyen bir inceleme, yazarın işten kopmasına, dalların birbirinden uzaklaşmasına ve çakışmalara yol açar. Ekip olarak makul bir süre belirleyin, örneğin "bir iş günü içinde ilk yanıt". İnceleme yapmayı, kendi kodunuzu yazmak kadar önemli bir iş olarak görün.

Tek kişilik projelerde

Tek başınıza çalışıyorsanız bile, değişikliği bir dalda yapıp birleştirmeden önce farkı bir gün sonra taze gözle okumak, kendi kodunuzu incelemenin şaşırtıcı derecede etkili bir yoludur.

İyi bir kod incelemesinin amacı mükemmel kod değil, dünkünden daha iyi bir kod tabanı ve birbirinden öğrenen bir ekiptir.