Darboğaz Yaratmadan Ölçeklenebilir Kod İncelemesi (Code Review)

Yazılım Teslimatı kod-inceleme, muhendislik-pratikleri

Kod incelemesi ya bağlamı ekibe dağıtır ya da her PR'ı tıkar. İncelemeyi hızlı, faydalı ve kıdemli mühendislere adil dağılan hale getiren üç yapısal adım.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Rutin PR'lar için 24 saatin altında inceleme SLA süresi, ekiplerin teslimat ritmini koruyan temel eşiktir.
  • Sıralı (round-robin) incelemeci ataması, yükü dağıtmak için 'ilk gören baksın' yaklaşımından çok daha etkilidir.
  • Yorum etiketleri (blocking, suggest, nit) neyin birleştirmeyi durdurduğunu netleştirir ve gereksiz tartışmaları bitirir.
  • İncelemeci yükü ölçülmelidir. Kıdemli mühendislerin tüm PR'ların %80'ini incelemesi yapısal bir sorundur.

On sekiz ayda 8 mühendisten 24 mühendise büyüyen bir ekipte kod inceleme süreci hiç güncellenmemişti. Sonuç olarak PR’lar ilk inceleme için ortalama 21 saat, onay için 2.4 gün bekliyordu. Herkes alışkanlıkla en kıdemli mühendisleri etiketlediği için tüm incelemelerin %70’ini dört kişi sırtlanmıştı ve en kıdemli mühendis haftada 14 saatini sadece PR okuyarak geçiriyordu.

Altı hafta içinde üç yapısal değişiklik uyguladık. İlk inceleme süresi 4 saatin, onay süresi 1 günün altına indi. İnceleme yükü 4 kişi yerine 14 mühendise dengeli biçimde dağıldı ve kimsenin haftalık inceleme mesaisi 3 saati geçmedi.

Değişiklik 1 ve 2: Açık İnceleme SLA’i ve Otomatik Rotasyon

İlk adım, bir PR’ın ilk inceleme için bekleyebileceği azami süre (SLA) üzerinde anlaşmaktır. Rutin PR’lar için 4 ila 8 çalışma saati, büyük PR’lar için 24 saat makul bir başlangıçtır. SLA bir temenni değil taahhüttür; atanan mühendis bu sürede bakamayacaksa PR’ı bekletmez, açıkça başka birine devreder.

İkinci adım, PR yazarının incelemeciyi elle seçmesi yerine CODEOWNERS ve yük dengeleyici bir bot aracılığıyla sıralı (round-robin) atama yapılmasıdır. Bu sayede her şeye aynı kıdemli mühendisin etiketlenmesi biter, yeni mühendisler kod tabanının farklı yerlerini görerek daha hızlı öğrenir ve bilgi tekelleşmek yerine ekibe yayılır.

Değişiklik 3: Bağlayıcı ve Tavsiye Yorum Taksonomisi

Kod incelemelerindeki en yaygın sürtünme, bırakılan 12 yorumdan hangilerinin birleştirme öncesi zorunlu olduğunun belirsiz kalmasıdır. PR şablonuna dört basit etiket eklemek bu belirsizliği bitirir:

  • blocking: Birleştirmeden önce mutlaka düzeltilmelidir.
  • suggest: İncelemecinin önerisidir; son kararı PR yazarı verir.
  • question: İncelemeci mantığı anlamak istiyordur; değişiklik şart değildir.
  • nit: Kozmetik veya ufak stil notudur; göz ardı edilebilir.

İyi bir kod incelemesi girinti veya isimlendirme avcılığı yapmaz; bunları linter araçlarına bırakır. İnsan incelemesinin asıl değeri tasarım niyetini, olası patlama yarıçapını (blast radius), test ve loglama yeterliliğini, API sözleşme uyumluluğunu ve güvenlik risklerini denetlemektir. Mühendis başına haftalık incelenen PR sayısını ölçün; sağlıklı aralık kıdemli mühendisler için haftada 3 ila 6 PR’dır.

Sıkça sorulanlar

Sıkça sorulan sorular

Her PR için iki onay zorunlu olmalı mı?

Hayır. Dikkatli yapılmış tek bir inceleme, yüzeysel yapılmış iki incelemeden iyidir. Kimlik doğrulama, faturalandırma ve veri taşıma gibi etki alanı geniş değişikliklerde iki incelemeci faydalıdır; rutin işlerde tek kişi yeterlidir. Her yerde iki onay şartı sorumluluk dağılmasına yol açar.

Yapay zeka destekli kod inceleme araçları hakkında ne düşünüyorsunuz?

Stil, bariz hatalar ve standart ihlalleri için ilk geçişte oldukça faydalıdır. Ancak niyet, mimari tasarım ve iş riski konusunda insan muhakemesinin yerini tutmaz. AI incelemesini kıdemli bir mühendis gibi değil, gelişmiş bir linter olarak konumlandırın.

Büyük çaplı yeniden yazım gerektiren bir PR ile nasıl başa çıkılır?

Yorum yazmayı durdurun ve 30 dakikalık canlı bir görüşme yapın. Önce küçük bir parçayı mı birleştireceğinize yoksa PR'ı kapatıp baştan mı başlayacağınıza karar verin. 40'tan fazla yorum almış uzun PR'lar asenkron yazışmayla nadiren çözülür.