Yalnızca kod yorumlarını kullanan bir kod incelemesi iyi bir fikir midir?

Ön koşullar

• Ekip DVCS kullanıyor
• IDE yorum ayrıştırmayı destekler (TODO vb. Gibi)
• CodeCollaborator gibi araçlar bütçe için pahalıdır
• Gerrit gibi araçlar kurulum için çok karmaşık veya kullanılamıyor

İş Akışı

• Yazar merkezi repo özelliği dalında bir yerde yayın yapıyor
• Hakem onu ​​getirir ve incelemeye başlar

• Bazı soru / sorun inceleyicileri için "REV" gibi özel bir etiketle yorum oluşturun. Bu etiket üretim kodunda OLMAMALIDIR - sadece inceleme aşamasında:

  $somevar = 123;
  // REV Why do echo this here?
  echo $somevar;
  

• Ne zaman gözden geçiren yorum yayınlamak bitirmek - sadece aptal mesaj "yorumlar" ile taahhüt ve geri iter

• Yazar, özellik dalını geri çeker ve yorumları benzer şekilde yanıtlar veya kodu geliştirir ve geri iter
• "REV" yorumları gittiğinde düşünebiliriz, bu inceleme başarıyla bitti.
• Yazar etkileşimli olarak özellik dalını yeniden basar, bu "yorum" taahhütlerini kaldırmak için ezer ve şimdi başarılı iç inceleme sonrasında olağan herhangi bir eylem geliştirmek veya yapmak için özelliği birleştirmek için hazır

IDE desteği

Tutulma ve netbeans'te özel yorum etiketlerinin mümkün olduğunu biliyorum. Tabii ki blablaStorm ailesinde olmalıdır.

Sorular

1. Sizce bu metodoloji uygulanabilir mi?
2. Benzer bir şey biliyor musun?
3. İçinde neler geliştirilebilir?

Fikir aslında çok güzel. Yaygın iş akışlarının aksine , incelemeyi doğrudan kodda tutarsınız, bu nedenle teknik olarak, bu iş akışını kullanmak için metin düzenleyiciden başka bir şeye ihtiyacınız yoktur . IDE'deki destek de güzel, özellikle altta inceleme listesini görüntüleme yeteneği.

Hala birkaç dezavantaj var:

• Çok küçük takımlar için iyi çalışır, ancak daha büyük takımlar neyin ne zaman, kim tarafından ve hangi sonuçla incelendiğini takip etmeyi gerektirir . Aslında bu tür bir izlemeye sahip olsanız da (sürüm kontrolü tüm bunları bilmenizi sağlar), kullanımı ve arama işlemi son derece zordur ve genellikle revizyonlar arasında manuel veya yarı manuel arama gerektirir.

• Gözden geçiren, gözden geçiren noktaları aslında nasıl uygulandığını bilmek gözden geçiren yeterli geribildirim olduğuna inanmıyorum .

  Aşağıdaki durumu düşünün. Alice ilk kez Eric'in kodunu gözden geçiriyor. Genç bir geliştirici olan Eric'in aslında kullanılan programlama dilinde en açıklayıcı olmayan sözdizimini kullandığını fark ediyor.

  Alice alternatif bir sözdizimi önerir ve kodu Eric'e geri gönderir. Doğru anladığına inandığı bu alternatif sözdizimini kullanarak kodu yeniden yazar ve ilgili // BLAyorumu kaldırır .

  Ertesi hafta, ikinci incelemenin kodunu alır. Eric'in nasıl çözdüğünü görmek için ilk incelemesinde bu açıklamayı yaptığını gerçekten hatırlayabilecek mi?

  Daha resmi bir inceleme sürecinde Alice, Eric'in kendisine bahsettiği sözdizimini yanlış anladığını fark etmek için derhal bir açıklama yaptığını ve ilgili kodun farkını görebildi.

• İnsanlar hala insanlar. Eminim ki bu yorumlardan bazıları üretim koduna girecek ve bazıları tamamen modası geçmişken çöp olarak kalacak .

  Elbette, aynı sorun başka herhangi bir yorumda da mevcuttur; örneğin üretimde çok sayıda TODO yorumu (en faydalı olanı da içerir: "TODO: Aşağıdaki kodu yorumlayın.") ve karşılık gelen kod olduğunda güncellenmeyen birçok yorum var.

  Örneğin, kodun orijinal yazarı veya gözden geçiren kişi bırakabilir ve yeni geliştirici incelemenin ne dediğini anlamayacaktır, bu nedenle yorum sonsuza kadar kalacaktır, birisinin onu silmek veya gerçekten neyi anlamak için çok cesur olacağını beklemektedir. diyor ki.

• Bu , yüz yüze incelemenin yerini almaz (ancak aynı sorun, yüz yüze yapılmayan diğer resmi incelemeler için de geçerlidir).

  Özellikle, orijinal inceleme açıklama gerektiriyorsa, gözden geçiren ve gözden geçiren bir tür tartışma başlatır . Sadece büyük BLA yorumlarıyla kendinizi bulamazsınız, aynı zamanda bu tartışmalar sürüm kontrolünün günlüğünü de kirletir .

• Ayrıca sözdizimi ile ilgili küçük sorunlarla da karşılaşabilirsiniz (bu da TODO yorumları için de geçerlidir). Örneğin, uzun bir "// BLA" yorumu birkaç satırda ortaya çıkarsa ve birisi bunu bu şekilde yazmaya karar verirse:

  // BLA This is a very long comment which is way beyond 80 characters, so it actually
  // fills more then one line. Since the next lines start with slashes, but not "BLA"
  // keyword, the IDE may not be able to show those lines, and display only the first one.
  

• Ve son olarak küçük ve çok kişisel bir not olarak: "BLA" yı anahtar kelime olarak seçmeyin. Kulağa çirkin geliyor. ;)

Koddaki yorumları tamamlayıcı bir belge ile tamamlarım. Bu, bulguları özetler ve yorumlar kaldırıldıktan sonra devam eder. Bunun avantajları:

• kompaktlık. Kişi, geçirilen bir işaretçinin boş olup olmadığını (veya kullandığınız dilde sık karşılaşılan başka bir başlangıç ​​hatası) rutin olarak kontrol edemezse, gözden geçiren kişi bu konuda düzinelerce REV yorumu bırakabilir ve belgede " Hepsini listelemeden önce işaretçilerin kontrol edilmediği 37 yer buldum
• övgü yeri. Gibi bir yorum REV this is a nice designbiraz garip görünüyor, ancak kod incelemelerim genellikle onayın yanı sıra onayları da içeriyor
• etkileşim. Örnek yorumunuz "bunu neden yaptınız?" ve çok tipik bir örnek. Yalnızca yorum yapma yaklaşımı bir görüşmeyi desteklemez. Kişi kodunu değiştirip yorumu silebilir veya yorumu silebilir. Ama "bunu neden yaptın?" ve "lütfen bunu değiştir, yanlış" aynı şey değildir.
• kayıt tutmak. Daha sonraki bir gözden geçiren, kodun gerçekten değiştirilip değiştirilmediğini veya yorumların kaldırıldığını kontrol edebilir. Ayrıca yorumların "araçta alındığını" ve geliştiricinin bir sonraki incelemede artık aynı hataları yapmadığını kontrol edebilirler.

Ayrıca, inceleme yapmak ve incelemeye yanıt vermek için bir iş öğesi kullanır ve checkin'leri onunla ilişkilendiririm. Bu, eski bir değişiklik kümesindeki yorumları bulmayı ve her birinin başka bir değişiklik kümesinde nasıl ele alındığını görmeyi kolaylaştırır.

Diğerleri bu yaklaşımın sınırlamalarından bahsetti. Gerrit gibi araçların takılmasının zor olduğunu söylediniz - phabricator'a bir göz atmanızı öneririm (http://www.phabricator.com). Facebook'un yıllardır kullandığı ve son zamanlarda açık kaynaklı olan kod inceleme sistemidir. Kurulumu zor değil, mükemmel iş akışlarına sahip ve diğer yorumlarda belirtilen tüm sorunları çözüyor.