Kod incelemesi daha iyi olabilir
(tigerbeetle.com)- 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-reviewadlı 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-leasekullanı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-reviewfikri şö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-reviewyaklaşı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
2 yorum
git-review yaklaşımının iyi olup olmadığından emin değilim ama GitHub tabanlı PR incelemesinin korkunç olduğu konusunda hemfikirim..
Hacker News görüşleri
Kod incelemesinde uzun zamandır rahatsız olduğum şey, gerçekten faydalı geri bildirimin (önemsiz zevk tercihleri dışındaki türden) neredeyse her zaman çok geç gelmesi. İncelemenin tekil ya da nadir sonucu olarak "bunu baştan farklı bir tasarımla yeniden yapmak gerekiyor" ya da "aslında bu işi yapmaya hiç gerek yoktu" denilen durumlar ortaya çıkıyor. Sanki tüm paydaşların gerçekten dahil olup değişiklik üzerine ciddi ciddi düşündüğü tek an kod incelemesiymiş gibi. Toplantılarda ya da Jira ticket'larında bir şeyler konuşulmuş olabilir, ama çoğu zaman organizasyondaki başka bir ekipten ya da departmandan biri bu değişikliği ancak kod inceleme bildirimi alınca öğreniyor. Ben de başka bir ekip garip bir şey uyguladığında, bunu ilk kez çoğunlukla kod inceleme bildirimiyle fark ediyorum. Herkesin önceden her şeyi takip etmesini beklemek gerçekçi değil. 90'larda üniversitedeki derslerde tasarım incelemeleri de yapılıyordu, ama gerçek iş hayatında bunu hiç görmedim. Tasarım incelemesinin tüm sorunları önceden yakalayacağını da sanmıyorum.
Yazılım mühendisliği dünyasında gerçek mühendislik pek yok. Sektörün, düzgün mühendislik süreçlerinin yavaşlığını kabullenememesi gibi bir taraf da var. Çoğu yazılım ölümcül değil; bug'lar ve hatalar sonradan düzeltilebiliyor. Köprüler, fabrikalar, uçak motorları gibi başarısızlığın tolere edilmediği alanlarla kıyaslandığında risk seviyesi ve sonradan yama yapabilme imkanı çok farklı.
Bizim ekip 4-6 kişilik küçük bir geliştirici grubu. Yeni bir özellik geliştirirken kafamda kaba taslak oluşur oluşmaz hemen ekip arkadaşlarımla konuşuyorum. Herkes böyle yaptığı için kod incelemeleri daha çok code smell gibi küçük şeylere odaklanıyor, genel mimari ise genelde önceden 2-3 kişi tarafından belirleniyor. Ekip üyeleri koda katılmıyorsa birbirlerinin koduna dokunmak istemiyor ve işler kötüye gidiyor. Ölçek daha büyük olsa bile, sorumluluk doğru paylaşıldığında bunun sorunsuz yapılabileceğine inanıyorum.
Tüm paydaşların yalnızca kod incelemesi aşamasında devreye girmesi, Git'in ya da bir versiyon kontrol sisteminin sorunu değil; organizasyonun sorunu. PR oluşturulmasının arka planı, ticket tartışmaları ve karar alma süreci paylaşılamıyor. Bu, işlevsiz bir organizasyon örneği; basılı kitap ortaya çıktığında ancak herkes bir araya gelip gerçekten dahil oluyor diye yayıncılık sürecini suçlamak gibi.
Bizim organizasyonda temel tasarım kararları için mutlaka RFC yazılır. Neyin temel tasarım kararı olduğuna ekip içinde duruma göre özerk biçimde karar verilir. Jira'da epic aşamasında ayrıntılı uygulama yöntemi belirlenmemişse, önce RFC yazılması atanır. RFC bazen sadece bizim ekip için olur, bazen de tüm yazılım ekibi için; ikincisinde herkes iki haftada bir yapılan toplantıdan önce okuyup yorum bırakabilir. Zor olsa da RFC tabanlı işbirlikçi tasarım süreci olmayan yerlere göre çok daha iyi.
Deneyimime göre tasarım incelemesi konusuna katılıyorum. Eskiden resmi tasarım belgeleri ve incelemeler yapıyorduk ama sonra prototipleme ve yinelemeli tasarıma geçtik. Tasarım aşamasında önemli detayları sık sık atlıyorduk ve zaten çok zaman harcandığı için sonrasında üstünkörü geçiliyordu. Tüm ekibin toplanıp inceleme yapması da verimsizdi; sonuçta sorunlar yine kod inceleme sürecinde ortaya çıkıyordu. Zaten iyi tasarım belgesi yazamayan ya da motivasyonu düşük çok insan var. Sonuç olarak 5 kişiden fazlasında bu verimsizlikten kaçınmak zor. İdeal ortam, PO ile ana kullanıcıların ve yaklaşık 5 geliştiricinin birlikte olduğu yapı.
HN'de stacked pull request hakkında yazılanları görmek çok ilginç. Eskiden graphite.dev'i başlattığımızda, Facebook ya da Google geçmişi olmayanların bu akışı çoğu zaman bilmediğini görürdük. Kod inceleme trendlerinin son 3-4 yılda inanılmaz hızlı değişmesini izlemek eğlenceli.
Mercurial öncesi arcanist kullanıcısı olarak, hâlâ büyük PR'lar ve merge commit'lerle uğraşan ekiplere Graphite'ı aktif biçimde öneriyorum. Özellikle PR'larla entegrasyonu mümkün kılmak için gösterilen çaba ve çıkan sonuç beni çok etkiledi. Keşke Graphite'ın, repo'yu daha sert varsayımlar yapabilecek şekilde başlatan ve daha güçlü kabullerle çalışan bir prescriptive modu olsa.
Graphite harika bir çözüm olsa da fiyatı epey yüksek ve satın alma kararı vericilerini ikna etmek zor. Graphite gibi iyi araçların açık kaynak olması ya da GitHub'a gömülü gelmesi umuluyor.
fig workflow'u özlediğim de oluyor
Yakın zamanda CodeRabbit'te yaşanan güvenlik olayı yüzünden, LLM ile kod tabanını entegre eden yeni araçları test etmeye çekiniyorum. İlginç yeni deneyler güvenlik sorununa çok kolay dönüşebiliyor.
stacked pull request özünde gereksiz bir karmaşıklık ekliyor. Sık ve küçük değişiklikler çok daha iyi bir geliştirme pratiği. trunk-based development ya da continuous integration bu amaca çok daha uygun.
Giderek daha fazla geliştirici, "inceleme araçları nasıl görünmeli" konusunda aynı noktaya geliyor. Artık asıl mesele, bunu gerçekten uygulanabilir ve sürdürülebilir hale getirecek organizasyonlar ve oyuncular. Son dönemde git change-id'nin gelmesi iyi bir gelişme oldu (jj, git butler, gerrit vb.'ye teşekkürler). Graphite ya da GitHub kendi kullanıcılarına dönük çözümlere odaklanıyor; herkes için açık bir yön izlemiyorlar. Sayısız istemci tabanlı komut satırı aracı da pek etkili değil. Gerçekten gereken şeyler şunlar:
GitHub'la ilgili en büyük şikayetim, uygulamanın aşırı yavaş olması. Gerçekten tarayıcı sekmesini donduracak kadar yavaş. Şimdiye kadar kullandığım en iyi kod inceleme aracı Azure DevOps'tu.
Microsoft ortamında .NET geliştirirken Azure DevOps kullandım; gerçekten .NET ekosistemine çok iyi uyan bir araç.
GitLab'ı ciddi biçimde kullanıp kullanmadığını merak ediyorum. Ben big 4 içinde en çok GitLab'ı seviyorum.
DevOps'un tam olarak hangi yönünü bu kadar sevdiğini merak ediyorum. Her gün kullanıyorum ama bana GitHub'a oldukça benzer geliyor. Hatta GitHub'daki önerilen değişiklikleri otomatik uygulama özelliğini özlediğim oluyor.
Büyük ölçekli JavaScript kullanımıyla hızlı sürüm baskısı birleşince böyle yavaş ortamlar ortaya çıkıyor. Yine de Atlassian'dan daha iyi.
Git'i doğrudan kod incelemede kullanma fikri çekici. Değişikliklerle lokalde doğrudan oynayabilmek kullanışlı. İncelemenin neden mutlaka tek bir commit'e odaklanması gerektiğini anlamıyorum; inceleyenin kendi yorumlarını ya da düzeltmelerini doğrudan PR branch'ine commit etmesi gibi bir yaklaşım da ilginç. Bu, geleneksel GitHub flow ile Linux'un mailing list ve patch akışının bir hibriti.
GitHub PR'larının salt okunur olup olmadığını merak ediyorum. Bir ekip arkadaşımın "suggestion" yorumu ile doğrudan düzeltme önerdiğini ve tek tıkla o commit'e uygulandığını görmüştüm.
İnceleme commit'inin tekil olması gerektiği fikri tuhaf. Birden fazla kişi inceleme yaparsa eşzamanlı düzenleme sorunları da çıkar ve bu kodun yapısına da uymuyor. İncelemelerin de ayrı branch'lerde yürütülüp sonunda squash & rebase yapılması daha doğal. Tartışma uzarsa yorum commit'leri de zincir halinde kalabilir. Önemli olan, bu verinin main branch dışında bir yerde saklanması.
Kod incelerken branch'i lokale çekip soft-reset yaptıktan sonra, sanki ben yazmışım gibi bakmayı tercih ediyorum. Commit'ler iyi bölünmemişse, ekip arkadaşlarının her birinin bunları ayrıca ayırıp incelemesi gerekiyor; bu da verimsiz. İncelenen şey çok büyükse, birinin onu tamamen anladığını söylemek zor. Bütün, sadece parçaların toplamı değildir.
Kolay kod incelemesi için örnek bir shell fonksiyonu paylaşıyorum. Clean tree durumunda review branch'ini ön ayarlı şekilde checkout ediyor, nvim'de diff'i gösteriyor ve iş bitince branch temizliğini otomatik yapıyor.
İyi commit'ler ve bunlardan iyi PR'lar üretmek de en az iyi kod yazmak kadar önemli bir beceri. Ama gerçekte PR bölme, commit message yazma gibi konularda zayıf olan geliştirici sayısı sanıldığından fazla.
Veri bilimi ekibinde paralel çalışanlar, kod incelemesi için 2-3 branch checkout ederek kullanıyor.
PR incelemesi için Neovim'de https://github.com/sindrets/diffview.nvim kullanıyorum. VSCode diff'ine benzer bir arayüz sunuyor ama Vim'in diff modundan yararlanıyor. Hafif incelemeler için
git log -p --function-contextda faydalı.Bir kişinin ilk draft'ı yazıp başka birinin bunu parlatıp merge ettiği çalışma biçimi ilgimi çekiyor. Bunu gerçekten deneyen var mı diye merak ediyorum.
Gerçek kodlamanın %90'ından fazlasını tek kişinin yaptığı, inceleyenin ise son entegrasyon ve merge sorumluluğunu doğrudan üstlendiği tarza katılıyorum. Önceki iş yerimde merge işlemini inceleyen kişi yapmak zorundaydı; büyük değişikliklerde sadece yorum iletilirdi. Birinden tek tek onay butonuna basmasını istemekten çok daha verimli.
İncelenen kodun yazımına katkı verince, çok daha derin geri bildirim verebildiğimi hissediyorum. Böyle bir yapı, bunu "benim kodum/senin kodun" değil "bizim kodumuz" olarak görmeyi sağlıyor. TDD gibi yinelemeli ve işbirliği odaklı kültürlerle iyi uyuşuyor.
Bu yaklaşım asenkron pair programming'e benziyor.
trunk-based development içinde pair programming kullanan insanlar tanıyorum. İki kişi birlikte kod yazıyor, tamam diyorsa doğrudan main'e merge ediyorlar; testler geçerse anında deploy. Pratikte gerçekten çalışıyor.
GitHub Pull Request eklentisini VSCode'da kullanarak lokal inceleme yapıyorum; oldukça kullanışlı. Editörün içinden doğrudan yorum bırakıp inceleme yapılabiliyor.
GitHub web'de değişen dosya sayısı çok olunca dosyalar gizleniyor, ama VSCode'da rahatça gezinebiliyorsun; bu yüzden deneyim çok daha akıcı. Bu özelliğin VSCode/GitHub kombinasyonunda yapılabildiğine göre, başka editörlere de genişletilebileceğini tahmin ediyorum.
Evet, daha iyi ama yine de GitHub ile VSCode arasındaki çift taraflı vendor lock-in oldukça derin.
GitHub web'de PR açıp "." tuşuna basarak doğrudan VSCode web'de inceleme yapmak da çok daha iyi bir deneyim.
Git'e birinci sınıf change ID gelmesi haberi harika! Bu, Facebook'taki Phabricator diff revision tracking'e benziyor. Bununla ilgili daha ayrıntılı bakabileceğim bir bağlantı var mı?
Sourcehut'tan da bahsetmek isterim. Klasik patch/issue/bug/tartışma akışını e-postayla sürdürme geleneğini devam ettiriyor ve mailing list ile CI'a entegre oluyor. Drew Devault'un git-send-email.io ve git-am.io sitelerinde patch gönderip alma yöntemleri için kaynaklar da var.