Kod İncelemesini Bir Öğrenme Kültürüne Dönüştürmek

Code Review'ı bir denetim mekanizması olmaktan çıkarıp ekip için bir öğrenme kültürüne dönüştürmenin yolları.

1. Giriş: İncelemenin İki Yüzü

Kod incelemesi (code review) çoğu ekipte bir kapı bekçiliği ritüeline dönüşür. İnceleyen kişi hata avlar, yazan kişi savunmaya geçer ve süreç bir onay damgası almaktan ibaret hale gelir. Oysa kod incelemesinin en değerli çıktısı birleştirilen kod değil, ekibin biriken ortak bilgisidir. İyi yürütülen bir inceleme süreci, her pull request’i (PR) küçük bir mentorluk seansına dönüştürür.

Bu makale, incelemeyi bir kalite kapısından bir öğrenme aracına nasıl çevireceğinizi anlatır. Odak noktası araçlar değil, yorumların tonu, yapısı ve niyetidir.

2. Neden Çoğu İnceleme Öğretmez?

Öğretmeyen incelemelerin ortak belirtileri vardır:

Emir kipi: “Bunu değiştir” der ama nedenini söylemez.
Sadece kusur arama: Yalnızca yanlışlar işaretlenir, iyi yapılan hiçbir şeye değinilmez.
Bağlam eksikliği: Yorum, arkasındaki ilkeyi açıklamaz, dolayısıyla yazan kişi bir sonraki sefere aynı hatayı yapar.
Statü oyunu: İnceleme, kıdemli geliştiricinin haklılığını kanıtladığı bir arenaya döner.

Öğrenmenin gerçekleşmesi için yorumun, kodun ötesine geçip altındaki gerekçeyi taşıması gerekir.

3. Yorumun Niyetini Etiketlemek

Bir yorumun ne kadar bağlayıcı olduğunu netleştirmek, gereksiz gerilimi büyük ölçüde azaltır. Yaygın bir yöntem, her yoruma bir etiket eklemektir:

blocking: Birleştirmeden önce mutlaka düzeltilmeli.
suggestion: Daha iyi olur ama zorunlu değil.
question: Anlamak için soruyorum, eleştiri değil.
nit: Çok küçük, isteğe bağlı bir detay.
praise: İyi yapılmış bir şeye işaret.

Örnek:

nit: Buradaki guard yerine erken return kullanmak okunabilirliği biraz artırabilir, ama mevcut hali de gayet doğru.

question: Bu force unwrap’in güvenli olduğundan emin olabilmek için soruyorum, bu değer hiç nil olabilir mi?

Yazan kişi artık hangi yorumun yolu kapattığını, hangisinin sadece bir fikir olduğunu net görür.

4. Emir Yerine Soru, Kural Yerine Gerekçe

Karşılaştıralım. Aşağıdaki Swift kodunda bir hata var:

func fetchUser(id: String?) {
    let userId = id!
    networkClient.getUser(userId) { result in
        self.user = try! result.get()
    }
}

Öğretmeyen bir yorum:

Force unwrap kullanma.

Öğreten bir yorum:

blocking: Buradaki id! ve try!, id nil olduğunda veya istek başarısız olduğunda uygulamayı çökertir. Hatayı zarif şekilde ele almak için optional binding ve Result’ın hata dalını kullanabiliriz:
func fetchUser(id: String?) {
    guard let userId = id else {
        logger.warning("fetchUser nil id ile çağrıldı")
        return
    }
    networkClient.getUser(userId) { [weak self] result in
        switch result {
        case .success(let user):
            self?.user = user
        case .failure(let error):
            self?.handle(error)
        }
    }
}
Bu yaklaşım hem çökmeyi önler hem de hatayı loglamamıza imkan verir.

İkinci yorum aynı kusuru işaret eder ama bir ilke (zarif hata yönetimi), bir alternatif ve bir gerekçe sunar. Yazan kişi bunu bir daha unutmaz.

5. Yazanın Sorumluluğu: İncelenebilir PR Üretmek

Öğrenme kültürü tek taraflı değildir. PR’ı açan kişi de incelemeyi kolaylaştırmakla yükümlüdür:

Küçük PR: 400 satırın altındaki PR’lar çok daha dikkatli incelenir. Devasa PR’larda inceleyen kişi yorulur ve sadece onaylar.
Niyeti açıklayan açıklama: PR ne yapıyor, neden yapıyor, hangi alternatifler elendi?
Kendi kodunu önce kendin incele: PR’ı açmadan önce diff’e bakıp belirgin sorunları işaretlemek, inceleyenin yükünü azaltır.

Faydalı bir PR şablonu:

## Ne değişti?
Kısa özet.

## Neden?
Hangi sorunu çözüyor, hangi issue'ya bağlı.

## Nasıl test edildi?
Manuel adımlar veya eklenen testler.

## İnceleyenin özellikle bakmasını istediğim yer
Belirsiz kaldığım veya geri bildirim istediğim kısım.

6. Sıradan Olanı Otomatikleştir

İnsan incelemesinin değeri öğretmektedir, biçimlendirme tartışmak değil. Girinti, boşluk, isimlendirme kuralı gibi tartışmalar otomatik araçlara devredilmelidir. Böylece insanlar tasarım ve mantık gibi öğrenilmesi gereken konulara odaklanır.

Örneğin SwiftLint yapılandırması:

# .swiftlint.yml
disabled_rules:
  - trailing_whitespace
opt_in_rules:
  - force_unwrapping
  - empty_count
  - first_where
line_length:
  warning: 120
  error: 160
identifier_name:
  min_length: 3

Bu kurallar CI üzerinde otomatik çalıştığında, inceleme yorumlarının hiçbiri “noktalı virgül” veya “boşluk” hakkında olmaz. Tüm enerji daha derin konulara kalır.

7. Övgü de Bir Geri Bildirimdir

Öğrenme kültüründe yalnızca hatalar değil, iyi yapılan şeyler de görünür kılınır. Bir geliştirici zarif bir çözüm yazdığında bunu işaretlemek, o davranışı tüm ekibe yayar:

praise: Bu retry mekanizmasını exponential backoff ile yazman çok iyi olmuş, ağ kesintilerinde gereksiz yük oluşturmayı önlüyor. Diğer servis çağrılarında da örnek alabiliriz.

Bu tür yorumlar maliyetsizdir ama psikolojik güvenliği ve tekrar gözden geçirme isteğini ciddi şekilde artırır.

8. Senkron ve Asenkron İncelemeyi Dengelemek

Karmaşık veya kavramsal bir değişiklik söz konusu olduğunda, yazılı yorum alışverişi yetersiz kalabilir ve gerginlik üretebilir. Bu durumlarda kısa bir eşli inceleme (pair review) çok daha öğreticidir. Pratik bir kural:

Üçüncü tur yorum alışverişine gelindiyse, konuşmayı yazıdan canlıya taşıyın.
Mimari kararlar PR’da değil, PR öncesinde bir tasarım konuşmasında çözülmelidir.

Asenkron inceleme ölçeklenir, senkron inceleme öğretir. İkisi birbirini tamamlar.

9. Yanlış Metrikten Kaçınmak

Bazı ekipler inceleme sürecini “kişi başı bulunan hata sayısı” veya “yorum sayısı” gibi metriklerle ölçmeye çalışır. Bu metrikler ters teşvik üretir: insanlar öğretmek yerine puan toplamak için anlamsız yorum yazar. Sağlıklı sinyaller daha yumuşaktır:

PR’ların ilk açılıştan birleşmeye kadar geçen süresi makul mu?
Yeni katılan biri ilk haftalarında incelemelerden gerçekten bir şey öğreniyor mu?
Yorumların tonu yapıcı mı?

Bunlar sayılarla değil, kültürün gözlemiyle anlaşılır.

10. Sonuç

Kod incelemesini bir öğrenme kültürüne dönüştürmenin sırrı tek bir araçta değil, niyetin yön değiştirmesindedir. Hedef hatayı yakalamaktan, bilgiyi yaymaya kayar. Yorumlar emir değil gerekçe taşır, etiketlerle netleşir, sıradan tartışmalar otomatikleştirilir ve iyi iş açıkça takdir edilir. Böyle bir ekipte her PR, kodun yanı sıra geliştiricileri de büyütür.