Kod incelemesi daha iyi olabilir

• Geliştiriciler GitHub’ın kod inceleme deneyiminden büyük ölçüde memnun değil ve bunu iyileştirmek için yeni denemeler yapılıyor
• git-review adlı deneysel araç, kod incelemesini tarayıcı tabanlı web arayüzü yerine yerelde, doğrudan kodla birlikte ele alacak şekilde tasarlandı
• İnceleme, tek bir commit ile yönetiliyor; kodun içine yorum satırı gibi inceleme notları bırakılıyor ve inceleyenle yazar bu commit’i birlikte düzenleyerek ilerliyor
• Ancak inceleme sırasında kod değiştirildiğinde veya rebase edildiğinde, çatışma çözümü ve --force-with-lease kullanımı gibi noktalarda rahatsızlıklar ortaya çıkıyor; bu yüzden büyük bir başarı elde edemedi
• Sonunda yeniden web tabanlı incelemeye dönüldü; ancak inceleme durumunu doğrudan Git deposuna dahil etme fikri hâlâ çekici ve Gerrit-style Change-Id gibi yaklaşımlarla, Git’teki gelecekteki iyileştirmeler sayesinde daha iyi alternatifler ortaya çıkabilir

---

Kod inceleme sistemlerindeki sorunların fark edilmesi

• Günümüzde birçok kişi GitHub’ın kod inceleme sürecinden memnun değil
• Başlıca sorunlar, stacked pull request ve interdiff incelemesi için yetersiz destek olmasının yanı sıra şunlar:
  • İnceleme durumu depo içinde saklanmıyor
  • İnceleme için uzak öncelikli web arayüzü zorunlu
• Benim gördüğüm temel sorunlar, incelemenin yeterince merkeziyetsiz olmaması ve arayüzün verimsizliği

Kod yazma ve inceleme iş akışlarının karşılaştırılması

• İnsanlar kod yazarken yerelde bir editör kullanıyor
  • Bu ortam, düşük bellek ve NVMe gecikmesiyle çalışıyor ve kullanıcının kendine özgü iş akışına göre optimize edilebiliyor
• Kod incelemesinde de kaynak branch’i yerelde pull edip çalışmayı tercih ediyorlar
  • Magit gibi araçlarla yalnızca diff değil, tüm kod bağlamı da gezilebiliyor
  • Test çalıştırma, kod tanımına gitme, refactoring deneme gibi güçlü geliştirme ortamı olanaklarından yararlanılabiliyor
• Buna karşılık, PR üzerine geri bildirim bırakmak için tarayıcıya geçmek gerekiyor; web arayüzü yavaş kalıyor ve büyük diff’lerde yazı girişi gecikmesi bile ciddi oluyor

İdeal kod inceleme arayüzü ve saklama yapısı

• Aslında yorumu doğrudan kod içine satır içi olarak bırakmak ya da kodu doğrudan düzeltmek en doğal yaklaşım

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Veriler yerel Git deposunda değil de uzak bir veritabanında saklandığında, gecikme ve vendor lock-in sorunları da ortaya çıkıyor

git-review fikri ve pratikte yaşanan deneyim

• git-review fikri şöyle:
  • Kod incelemesi, PR branch’inin en üstünde duran tek bir commit ile yapılıyor
  • Bu commit’e özel işaretçiler taşıyan kod yorumları ekleniyor
  • İnceleyen ve yazar, bu commit’i sırayla değiştirerek push --force-with-lease tabanlı bir iş birliği yürütüyor
  • Tüm yorumlar çözüldü olarak işaretleniyor (//? resolved) ve inceleme bitince bir revert commit eklenerek kayıt bırakılıyor
• Fikir basit ve pratik görünse de gerçekte şu sorunlar yaşanıyor:
  • İnceleme sırasında kod değiştiğinde, alt commit’lerde veya yeni commit’lerde yorumlarla sık sık çatışma çıkıyor
  • force-push süreci, ekip içi sürtüşmeyi artırıyor ve işi daha karmaşık hâle getiriyor
  • Kod değişiklik geçmişiyle inceleme akışı arasında uyuşmazlık oluşuyor ve merge conflict yönetimi zorlaşıyor

Yeni gelişmeler ve gelecekteki olasılıklar

• İleride Git upstream’e Gerrit tarzı Change-Id gelme ihtimali var
  • Böylece commit bazlı revizyon geçmişini izlemek kolaylaşacak ve interdiff incelemesi desteği genişleyebilecek
  • Ancak bunun git-review yaklaşımıyla bazı çakışmaları olabilir
  • Yeni Change-Id yapısı, inceleme yorumlarını doğrudan commit’in içine eklemek gibi farklı yaklaşımları mümkün kılabilir

Sonuç ve bakmaya değer sistemler

• Şimdilik yeniden web arayüzü tabanlı kod incelemesine dönülmüş durumda
• Daha iyi bir çözüme duyulan ihtiyaç ise sürüyor
• Bakmaya değer ilgili sistem ve araçlar:
  • Fossil: Tüm bilgileri depo içinde saklayan bir SCM sistemi
  • NoteDb: Gerrit’in inceleme durumu geçmişini Git ile birleştirir
  • git-bug: Sorun bilgilerini Git içinde saklar
  • git-appraise: İnceleme bilgilerini Git’in kendisinde tutar
  • prr: Editör içinde GitHub API ile entegre çalışan bir inceleme arayüzü sunar
  • How Jane Street Does Code Review: Daha iyi bir gerçek dünya örneği sunar
  • git-pr: Tüm PR iş akışını Git’in yerel özellikleriyle değiştirmeyi amaçlayan bir proje

Kapanış

• Hâlâ kusursuz bir çözüm yok ve daha iyi bir geliştirici deneyimi için denemeler sürüyor
• Gelecekteki gelişmeler için beklenti yüksek