Bazı geliştiriciler, "interdiff" kod incelemesini tercih ediyor

Neden bazı insanlar "interdiff" kod incelemesini sever

Gerrit kod inceleme aracının değerlendirilmesi

• Gerrit, Git deposuyla birlikte çalışan açık kaynaklı bir kod inceleme aracıdır
• Depoya yamalar yazabilir ve inceleme için gönderebilirsiniz
• Diğer kişilerin yazdığı kodu inceleyip düzeltilmesi gereken sorunları işaret edebilirsiniz
• Kod incelemesi genel olarak iyi bir fikirdir
• Açık kaynak projelerde kod birleştirilebilir; bu da sorumluluğu ve teknik borcu artırır

Çeşitli kod inceleme araçları

• Gerrit, GitHub, Phabricator, hata takip sistemine .patch dosyası yükleme, git send-email ile e-posta gönderme gibi çeşitli araçlar vardır
• Her araç farklı düzeylerde işlev görebilir

İdeal yama serisi

• 3 yamadan oluşan bir seri, kod tabanının evrimini adım adım gösterir
• Değişiklikler mantıksal olarak ayrılmalı ve her yama tek başına uygulanmış gibi okunabilmelidir
• Kod incelemesi yoluyla bu ideal seri gözden geçirilir

GitHub'un kod inceleme yöntemi: "diff soup"

• GitHub başlangıçta, mevcut commit'lerin üstüne yeni commit'ler ekleyerek inceleme yapılmasını teşvik etti
• Bu durum UX tasarımı ve çeşitli nedenlerden kaynaklanır
• İnceleme sürecinde birden fazla commit eklendiğinde, commit'ler arasındaki örtük ilişki karmaşık hale gelir
• git blame ve git bisect araçlarını kullanmak zorlaşır

Daha iyi yöntem: "interdiff" incelemesi (AKA git range-diff)

• Yeni commit'ler eklemek yerine, mevcut commit'lerin yeni sürümleri yayımlanır
• git range-diff kullanılarak commit sürümleri arasındaki fark karşılaştırılır
• İncelemeyi yapan kişi, tüm diff'i baştan okumadan artımlı inceleme yapabilir
• git blame ve git bisect araçları daha güvenilir çalışır

Ara açıklama: yama birleştirme stratejisi

• Yukarıdaki yöntem, birleştirme stratejisinden bağımsızdır (git rebase ile çok ebeveynli git merge commit'i gibi)

Ara açıklama: git rebase kötü mü?

• git rebase sorun değildir. Ancak başkalarının commit'lerini temel alacağı açık branch'lerde kullanılmamalıdır

Diğer notlar

Sonuç

• Interdiff inceleme sistemi, daha küçük ve ana branch'e daha hızlı birleştirilen yamaları teşvik eder
• Hem incelemeyi yapanlar hem de yazarlar için daha iyi bir kod inceleme deneyimi sunar

GN⁺ Özeti

• Bu yazı, kod inceleme araçları ve metodolojileri üzerine derinlemesine bir analiz sunar
• Interdiff inceleme yöntemi, kod incelemesinin verimliliğini önemli ölçüde artırabilir
• GitHub'un "diff soup" sorununu çözmeye yardımcı olur
• Kod inceleme aracı seçerken dikkate alınması gereken önemli unsurları ortaya koyar
• Benzer işlevlere sahip araçlar arasında GitHub, Gerrit ve Phabricator bulunur

[GN⁺]

Hacker News görüşleri

• GitHub'da yaygın olarak kullanılan iş akışı fazla emek gerektiriyor ve işbirlikçiler için yeterince net değil

  • İnceleyenin, geri bildirimin entegre edildiği farkı görmesini sağlayarak git blame ve git bisect'i bozmuyor
  • İnceleyen geri bildirimini entegre ederken git commit --fixup <güncellenecek commit'in hash'i> kullanılıyor
  • PR onaylandığında, fixup commit'lerini özgün commit'lerle birleştirmek için git rebase --interactive origin/main --autosquash kullanılıyor
  • Son olarak git push --force-with-lease ile birleştiriliyor
  • Uzun komutları kolayca girmek için otomatik tamamlama kullanılıyor

• GitHub'un kod inceleme yöntemi verimsiz ve bu yüzden Phabricator ile süreç manuel olarak yürütülmüş

  • Açık ve belirgin bir UI olsaydı daha iyi olurdu

• GitHub'un kod inceleme yönteminden daha iyi bir sistem isteniyor

  • Küçük hata düzeltme patch'lerini hızlıca birleştirmek ve inceleme kapsamını daraltmak isteniyor
  • Bunların ayrı inceleme/PR olarak yapılması gerektiği söyleniyor, ancak bu da patch set'leri arasında bağımlılık sorunları doğuruyor

• Kod incelemeye yönelik yeni yaklaşımlar görmek her zaman ilgi çekici

  • Patch'leri birbirine bağımlı ayrı PR'lara bölmeyi düşünmüşler
  • GitContext gibi araçlar, bağımlılıkları korurken PR'ları küçük tutmaya yardımcı olabilir
  • Yapay zeka kullanılarak PR'lar ve incelemeler özetlenebilir, ayrıca doğru commit mesajları üretilebilir
  • İnceleyenler yalnızca son incelemeden bu yana yapılan değişiklikleri görebilir

• Interdiffs ilk kez Review Board'da tanıtıldı ve kod incelemede çok faydalı

  • Fix-it commit'leri uygun bir alternatif değil
    1. Upstream değişiklikleri görünmüyor
    2. Commit grafiğini karmaşıklaştırıyor
    3. Herkes Git kullanmıyor
  • Interdiffs, inceleyenin ilk inceleme isteğinden itibaren tüm güncellemeleri takip edebilmesini sağlıyor
  • Birden fazla commit tek bir inceleme isteği olarak yayımlandığında kullanışlı

• Gerrit kod inceleme sistemiyle deneyim var ve GitHub'un kod incelemesi verimsiz bulunuyor

  • Gerrit, birden fazla patch'in stack olarak dizilmesini destekliyor; bu da küçük patch'lerin kolay incelenmesini sağlıyor
  • GitHub'un arayüzü bir forum başlığı gibi görünüyor ve rebase geçmişini izleyemiyor

• Çeşitli kod inceleme sistemleri kullanılmış ve her birinin artıları ile eksileri var

  • Critique, Google'ın monorepo'su ve özelleştirilmiş VCS'si için optimize edilmiş
  • Gerrit, inceleyenler için iyi ama yazarlar için rahatsız edici
  • GitHub, yazar dostu ama inceleyenler ve ekip için verimsiz
  • Daha iyi kod inceleme araçları kullanmak önemli

• Gerrit kod inceleme sistemini kullandıktan sonra GitHub'un stacked PR yaklaşımı kullanışsız geliyor

  • GitHub, kod inceleme yorumlarına karşılık yapılan değişiklikleri düzgün göstermiyor
  • Bazı script'lerle stacked PR çalışmasını daha kolay hale getirmişler
  • ejoffe/spr ve spacedentist/spr gibi araçlar faydalı