Critique - Google'ın geliştirici memnuniyetini %97'ye çıkararak code review acısını azaltma yöntemi

xguru · 2023-12-11T10:32:02+09:00

Birçok eski Google çalışanının özlediği Google code review aracı "Critique" Google içinde yapılan araştırmaya göre geliştiricilerin %97'si Critique'ten memnun Google'ın code review kılavuzu Mükemmellikten ziyade sürekli iyileştirmeyi teşvik eder Kod tabanının durumunu korumak veya iyileştirmek Stil kılavuzunu takip etmek Her zaman bilgi paylaşmak: code review aracılığıyla dil özellikleri, kod tabanı ve ilgili diğer artefaktlar hakkında bilgi paylaşımı teşvik edilir Değişiklikleri küçük yazmak (yaklaşık 200 satır) Hafiflik için sıkı standartlar (kod değişikliklerini 24 saat içinde incelemek, mümkünse tek bir reviewer) Nezaket ve profesyonellik: güven ve saygı kültürünü sürdürmek önemlidir Critique: Google'ın code review aracı Mühendislerin kod değişikliklerini verimli biçimde inceleyip gönderilebilir hale getirmesini sağlar Yakın tarihli makaleye - Resolving code review comments with ML göre kapsamlı bir AI tabanlı code review aracı kullanılıyor Reviewer koda yorum bıraktığında Critique, ML tabanlı düzenleme önerileri gösterir Code review yazarı, tek bir düğmeye tıklayarak ilgili yorumu bütünsel olarak düzeltebilir Code review akışı Adım 1: Değişiklik yazımı CL (veya Pull Request), Google'ın şirket içi kod editörü Cider içinde yazılır Critique ve diğer şirket içi Google araçlarıyla sıkı biçimde entegredir; geliştirici verimliliğini artırır Prereview aracı: inceleme öncesinde değişiklikleri düzenler; farkları, build ve test sonuçlarını, stil kontrollerini gösterir Diff görünümü ve görselleştirme: sözdizimi vurgulama, çapraz referanslar, intraline diffing, boşlukları yok sayma, taşıma algılama özellikleri Statik analiz araçlarının sonuçlarını göstererek önemli bulguları öne çıkarır ve düzeltme önerileri sunar. Buna Critique içinde çalışan otomatik testler olan "presubmits" de dahildir Adım 2: Review talebi Pull request incelenmeye hazır olduğunda kod yazarı reviewer ekler ve resmi olarak incelemeye gönderir PR/CL incelemeye gönderildiğinde, mevcut kod anlık görüntüsünde henüz yoksa "Presubmits" çalıştırılır. Böylece incelemeye katılan herkes kodda sorun olup olmadığını görebilir Code review anonimleştirilerek kod yazarı reviewer'lardan gizlenebilir. Ancak Google, anonim code review ile "gerçek" code review arasında faydalı bir fark bulmamıştır Adım 3 ve 4: Değişiklikleri anlama ve yorum yapma Herkes değişikliklere yorum yapabilir; ayrıca review ilerlemesini takip etme ve yorumları çözme özellikleri sunulur Çözülmemiş yorumlar, değişiklik yazarının kesinlikle ele alması gereken iş kalemlerini ifade eder. Bu yorumlar, kod yazarı doğrudan yoruma yanıt verdiğinde "çözüldü" olarak işaretlenebilir Çözülmüş yorumlar arasında, değişiklik yazarının aksiyon almasını gerektirmeyebilecek isteğe bağlı veya bilgilendirici yorumlar yer alır Review durumunu kontrol etmeye yarayan bir dashboard ve belirli bir code review'e katılan kişilerin şu anda kimde sıra beklediğini görebildiği bir "Attention Set" vardır Adım 5: Değişikliğin onaylanması Yukarıda belirtildiği gibi, review'un kayda geçmesi için en az bir reviewer'dan LGTM (Looks Good To Me) alınmalıdır Kod yazarı yorum yaparken bunları doğrudan çözülmüş olarak işaretleyebilir, ancak çözülmemiş yorum sayısının 0 olması gerekir Ayrıca kodun gireceği kod tabanı bölümünün sahibinden onay ve readability onayı gerekir Tüm bunlar tek bir reviewer tarafından yapılabilir Adım 6: Değişiklikleri commit etmek Değişiklikler doğrudan Critique içinde submit edilir ve commit edilir Critique, değişiklik submit edildikten sonra da kullanışlıdır "Google araştırmacıları, Critique'in kullanım alanının code review'un ötesine geçtiğine dair güçlü kanıtlar buldu. Değişiklik yazarları Critique'i diff'leri incelemek ve analiz araçlarının sonuçlarına bakmak için kullanıyor. Bazı durumlarda code review, değişiklik geliştirme sürecinin bir parçası olarak işliyor; reviewer'lar, implementasyonun nasıl tamamlanacağına karar verebilmek için tamamlanmamış değişiklikler gönderebiliyor. Ayrıca geliştiriciler, değişiklik onaylandıktan sonra da submit edilmiş değişikliklerin geçmişini incelemek için Critique'i kullanıyor." Google'ın güncel code review istatistikleri Değişiklik yazma sıklığı: Medyan: haftada 3 değişiklik Yazarların %80'i haftada 7'den az değişiklik yapıyor Review sıklığı: Medyan: haftada 4 değişikliği review etmek Reviewer'ların %80'i haftada 10'dan az değişiklik işliyor Haftalık review için harcanan süre: Ortalama haftada 3,2 saat Medyan haftada 2,6 saat İlk geri bildirim bekleme süresi: Küçük değişiklik: ortalama 1 saatten az Çok büyük değişiklik: yaklaşık 5 saat Toplam review süreci süresi: Tüm kod boyutlarında ortalama gecikme: 4 saatten az Diğer şirketlerle karşılaştırma: AMD: 17,5 saat (onaya kadar geçen medyan süre) Chrome OS: 15,7 saat Microsoft projeleri: 14,7 saat, 19,8 saat, 18,9 saat Microsoft (başka bir araştırma): 24 saat Google çalışanları Critique'i neden seviyor? Statik analiz: kod için uygulanabilir geri bildirimi otomatik olarak sağlayan kapsamlı bir statik analiz araçları setine sahip. Bu sayede hem kod yazarı hem de reviewer zaman kazanıyor; reviewer'ın bariz noktaları tek tek belirtmesi gerekmiyor Yalnızca en son değiştirilen dosyalara odaklanma: sadece kodun en güncel "anlık görüntüsüne" odaklanılabiliyor. Önceki anlık görüntüler, commit'ler ve kod değişiklikleri gösterilmediği için kullanıcı arayüzü daha temiz Tanıdık side-by-side diff arayüzü: varsayılan olarak "son review'dan farklar" gösteriliyor Makine öğrenimi tabanlı öneriler: Google'ın yeni ML tabanlı öneri özelliği code review hızını olağanüstü artırıyor Diğer Google araçlarıyla sıkı entegrasyon: Critique, Google'ın IDE'si ve bug tracker'ı gibi diğer şirket içi araçlarla çok iyi entegre; bu da verimliliği artırıyor. Buna kod, yorum ve ticket'ların kolayca birbirine bağlanması da dahil 'Çalışma seti' takibi: sıradaki aksiyonu kimin alması gerektiği görülebiliyor Tatmin edici oyunlaştırma: Critique oyunlaştırma amacıyla tasarlanmamış olsa da Google çalışanları, Critique'in "yeşile döndüğü" ve PR'ın submit edilmeye hazır olduğu anda (tüm testler geçtiğinde, reviewer LGTM verdiğinde) bunun keyifli olduğunu söylüyor Reddit'teki yorumlar Çok miktarda kodu son derece verimli biçimde incelemeyi sağlayan harika klavye kısayolları Varsayılan olarak "son review'dan farkları" gösterir "Kod taşıma algılama" özelliği sayesinde kod değişikliklerine odaklanılabilir Reviewer ya da yazar fark etmeksizin, kimin aksiyon alması gerektiğini söyleyen harika özellikler sunar Chrome eklentisiyle birlikte kullanıldığında bildirim almak ve review kuyruğunu kontrol etmek kolaydır Şirket içinde herkes, içgörü toplamak için code review verileri üzerinde sorgu çalıştırabilir Kod ve yorumların otomatik bağlanması (ticket'lar ve taşıma/linkler dahil) Birden fazla tur kod içeren PR'lerin ilerleyişini çok daha kolay anlamak için PR analizleri, geçmişi ve yorumları tablo biçiminde görmek mümkündür İsteğe bağlı, bilgilendirme vb. yorum terimleri/etiketleri çok tutarlıdır Düşünceler ve çıkarımlar Bu özelliklerin çoğu bugün başka araçlarda da mevcut, ancak bu aracın sevilme nedeninin Google'a özgü iş akışları ve kod tabanıyla olan sıkı entegrasyonu ve aşırı derecede "kişiselleştirilmiş" olması olduğunu düşünüyorum Aynı zamanda bu, hiçbir şirketin Critique'i ve ilgili araçları birebir kopyalamasının gerçekçi olmadığı anlamına da geliyor. Örneğin bazı araçlar, monorepo yapısından kaynaklanan sorunlara özel olarak geliştirilmiş Critique'in kendisi open source olarak sunulmuyor olabilir, ancak Gerrit, Critique'e benzer bir araç. Bu da yine Google tarafından geliştirilen ve bakımı yapılan bir open source code review aracı Ancak Google'ın geliştirici verimliliği için ciddi emek ve düşünce harcadığını düşünüyorum. Araştırmalarını açıkça yayımlıyorlar ve çalışmalarından yararlı çıkarımlar elde edilebilir

(engineercodex.substack.com)

52 puan yazan xguru 2023-12-11 | 5 yorum | WhatsApp'ta paylaş

Birçok eski Google çalışanının özlediği Google code review aracı "Critique"
Google içinde yapılan araştırmaya göre geliştiricilerin %97'si Critique'ten memnun

Google'ın code review kılavuzu

Mükemmellikten ziyade sürekli iyileştirmeyi teşvik eder
Kod tabanının durumunu korumak veya iyileştirmek
Stil kılavuzunu takip etmek
Her zaman bilgi paylaşmak: code review aracılığıyla dil özellikleri, kod tabanı ve ilgili diğer artefaktlar hakkında bilgi paylaşımı teşvik edilir
Değişiklikleri küçük yazmak (yaklaşık 200 satır)
Hafiflik için sıkı standartlar (kod değişikliklerini 24 saat içinde incelemek, mümkünse tek bir reviewer)
Nezaket ve profesyonellik: güven ve saygı kültürünü sürdürmek önemlidir

Critique: Google'ın code review aracı

Mühendislerin kod değişikliklerini verimli biçimde inceleyip gönderilebilir hale getirmesini sağlar
Yakın tarihli makaleye - Resolving code review comments with ML göre kapsamlı bir AI tabanlı code review aracı kullanılıyor
- Reviewer koda yorum bıraktığında Critique, ML tabanlı düzenleme önerileri gösterir
- Code review yazarı, tek bir düğmeye tıklayarak ilgili yorumu bütünsel olarak düzeltebilir

Code review akışı

Adım 1: Değişiklik yazımı
- CL (veya Pull Request), Google'ın şirket içi kod editörü Cider içinde yazılır
- Critique ve diğer şirket içi Google araçlarıyla sıkı biçimde entegredir; geliştirici verimliliğini artırır
- Prereview aracı: inceleme öncesinde değişiklikleri düzenler; farkları, build ve test sonuçlarını, stil kontrollerini gösterir
- Diff görünümü ve görselleştirme: sözdizimi vurgulama, çapraz referanslar, intraline diffing, boşlukları yok sayma, taşıma algılama özellikleri
- Statik analiz araçlarının sonuçlarını göstererek önemli bulguları öne çıkarır ve düzeltme önerileri sunar. Buna Critique içinde çalışan otomatik testler olan "presubmits" de dahildir
Adım 2: Review talebi
- Pull request incelenmeye hazır olduğunda kod yazarı reviewer ekler ve resmi olarak incelemeye gönderir
- PR/CL incelemeye gönderildiğinde, mevcut kod anlık görüntüsünde henüz yoksa "Presubmits" çalıştırılır. Böylece incelemeye katılan herkes kodda sorun olup olmadığını görebilir
- Code review anonimleştirilerek kod yazarı reviewer'lardan gizlenebilir. Ancak Google, anonim code review ile "gerçek" code review arasında faydalı bir fark bulmamıştır
Adım 3 ve 4: Değişiklikleri anlama ve yorum yapma
- Herkes değişikliklere yorum yapabilir; ayrıca review ilerlemesini takip etme ve yorumları çözme özellikleri sunulur
- Çözülmemiş yorumlar, değişiklik yazarının kesinlikle ele alması gereken iş kalemlerini ifade eder. Bu yorumlar, kod yazarı doğrudan yoruma yanıt verdiğinde "çözüldü" olarak işaretlenebilir
- Çözülmüş yorumlar arasında, değişiklik yazarının aksiyon almasını gerektirmeyebilecek isteğe bağlı veya bilgilendirici yorumlar yer alır
- Review durumunu kontrol etmeye yarayan bir dashboard ve belirli bir code review'e katılan kişilerin şu anda kimde sıra beklediğini görebildiği bir "Attention Set" vardır
Adım 5: Değişikliğin onaylanması
- Yukarıda belirtildiği gibi, review'un kayda geçmesi için en az bir reviewer'dan LGTM (Looks Good To Me) alınmalıdır
- Kod yazarı yorum yaparken bunları doğrudan çözülmüş olarak işaretleyebilir, ancak çözülmemiş yorum sayısının 0 olması gerekir
- Ayrıca kodun gireceği kod tabanı bölümünün sahibinden onay ve readability onayı gerekir
- Tüm bunlar tek bir reviewer tarafından yapılabilir
Adım 6: Değişiklikleri commit etmek
- Değişiklikler doğrudan Critique içinde submit edilir ve commit edilir
- Critique, değişiklik submit edildikten sonra da kullanışlıdır
- "Google araştırmacıları, Critique'in kullanım alanının code review'un ötesine geçtiğine dair güçlü kanıtlar buldu. Değişiklik yazarları Critique'i diff'leri incelemek ve analiz araçlarının sonuçlarına bakmak için kullanıyor. Bazı durumlarda code review, değişiklik geliştirme sürecinin bir parçası olarak işliyor; reviewer'lar, implementasyonun nasıl tamamlanacağına karar verebilmek için tamamlanmamış değişiklikler gönderebiliyor. Ayrıca geliştiriciler, değişiklik onaylandıktan sonra da submit edilmiş değişikliklerin geçmişini incelemek için Critique'i kullanıyor."

Google'ın güncel code review istatistikleri

Değişiklik yazma sıklığı:
- Medyan: haftada 3 değişiklik
- Yazarların %80'i haftada 7'den az değişiklik yapıyor
Review sıklığı:
- Medyan: haftada 4 değişikliği review etmek
- Reviewer'ların %80'i haftada 10'dan az değişiklik işliyor
Haftalık review için harcanan süre:
- Ortalama haftada 3,2 saat
- Medyan haftada 2,6 saat
İlk geri bildirim bekleme süresi:
- Küçük değişiklik: ortalama 1 saatten az
- Çok büyük değişiklik: yaklaşık 5 saat
Toplam review süreci süresi:
- Tüm kod boyutlarında ortalama gecikme: 4 saatten az
- Diğer şirketlerle karşılaştırma:
  - AMD: 17,5 saat (onaya kadar geçen medyan süre)
  - Chrome OS: 15,7 saat
  - Microsoft projeleri: 14,7 saat, 19,8 saat, 18,9 saat
  - Microsoft (başka bir araştırma): 24 saat

Google çalışanları Critique'i neden seviyor?

Statik analiz: kod için uygulanabilir geri bildirimi otomatik olarak sağlayan kapsamlı bir statik analiz araçları setine sahip. Bu sayede hem kod yazarı hem de reviewer zaman kazanıyor; reviewer'ın bariz noktaları tek tek belirtmesi gerekmiyor
Yalnızca en son değiştirilen dosyalara odaklanma: sadece kodun en güncel "anlık görüntüsüne" odaklanılabiliyor. Önceki anlık görüntüler, commit'ler ve kod değişiklikleri gösterilmediği için kullanıcı arayüzü daha temiz
Tanıdık side-by-side diff arayüzü: varsayılan olarak "son review'dan farklar" gösteriliyor
Makine öğrenimi tabanlı öneriler: Google'ın yeni ML tabanlı öneri özelliği code review hızını olağanüstü artırıyor
Diğer Google araçlarıyla sıkı entegrasyon: Critique, Google'ın IDE'si ve bug tracker'ı gibi diğer şirket içi araçlarla çok iyi entegre; bu da verimliliği artırıyor. Buna kod, yorum ve ticket'ların kolayca birbirine bağlanması da dahil
'Çalışma seti' takibi: sıradaki aksiyonu kimin alması gerektiği görülebiliyor
Tatmin edici oyunlaştırma: Critique oyunlaştırma amacıyla tasarlanmamış olsa da Google çalışanları, Critique'in "yeşile döndüğü" ve PR'ın submit edilmeye hazır olduğu anda (tüm testler geçtiğinde, reviewer LGTM verdiğinde) bunun keyifli olduğunu söylüyor
Reddit'teki yorumlar
- Çok miktarda kodu son derece verimli biçimde incelemeyi sağlayan harika klavye kısayolları
- Varsayılan olarak "son review'dan farkları" gösterir
- "Kod taşıma algılama" özelliği sayesinde kod değişikliklerine odaklanılabilir
- Reviewer ya da yazar fark etmeksizin, kimin aksiyon alması gerektiğini söyleyen harika özellikler sunar
- Chrome eklentisiyle birlikte kullanıldığında bildirim almak ve review kuyruğunu kontrol etmek kolaydır
- Şirket içinde herkes, içgörü toplamak için code review verileri üzerinde sorgu çalıştırabilir
- Kod ve yorumların otomatik bağlanması (ticket'lar ve taşıma/linkler dahil)
- Birden fazla tur kod içeren PR'lerin ilerleyişini çok daha kolay anlamak için PR analizleri, geçmişi ve yorumları tablo biçiminde görmek mümkündür
- İsteğe bağlı, bilgilendirme vb. yorum terimleri/etiketleri çok tutarlıdır

Düşünceler ve çıkarımlar

Bu özelliklerin çoğu bugün başka araçlarda da mevcut, ancak bu aracın sevilme nedeninin Google'a özgü iş akışları ve kod tabanıyla olan sıkı entegrasyonu ve aşırı derecede "kişiselleştirilmiş" olması olduğunu düşünüyorum
Aynı zamanda bu, hiçbir şirketin Critique'i ve ilgili araçları birebir kopyalamasının gerçekçi olmadığı anlamına da geliyor. Örneğin bazı araçlar, monorepo yapısından kaynaklanan sorunlara özel olarak geliştirilmiş
Critique'in kendisi open source olarak sunulmuyor olabilir, ancak Gerrit, Critique'e benzer bir araç. Bu da yine Google tarafından geliştirilen ve bakımı yapılan bir open source code review aracı
Ancak Google'ın geliştirici verimliliği için ciddi emek ve düşünce harcadığını düşünüyorum. Araştırmalarını açıkça yayımlıyorlar ve çalışmalarından yararlı çıkarımlar elde edilebilir

5 yorum

xguru 2023-12-17

Gerrit'e ChatGPT eklemeye yönelik girişimler de var gibi görünüyor
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

Bence en büyük fark, Critique'te art arda gelen bir dizi CL'yi inceleyebilmeniz. GitHub'da ise PR zinciri doğrudan desteklenmediği için bu rahatsız edici. Bu yüzden ya tek bir büyük PR'a dönüşüyor ya da önceki PR merge edilene kadar beklemek gerekiyor.

tested 2023-12-11

GitHub'da da benzer bir şey var, ne zaman açılacağını merak ediyorum
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

Statik analiz ve ml tabanlı öneriler yok ama yazıyı görünce GitHub inceleme özelliğine oldukça benzediğini düşündüm. GitHub incelemeyi sık kullanan biri olarak, Critique'in sunduğu diğer özelliklerin de daha fazla eklenmesi iyi olurdu.

xguru 2023-12-11

Google'ın kod inceleme kılavuzu [Korece çeviri]