Kod incelemelerine ayrılan süre

Kod yorumları yapıyorsanız

• Uygulamaya kıyasla kod incelemelerine ne kadar zaman harcıyorsunuz?
• Değişikliklerin ne kadarı kod incelemesinden geçiyor?
• çok şey olduğunu / daha fazla olması gerektiğini mi düşünüyorsunuz?

Etkinlik hakkında herhangi bir çalışma var mı?

cevaplar için hepinize teşekkür ederim, böyle bir soru için bir "kazanan" seçmek zor, diğer cevaplar da çok değerli bilgi var.

İşimde kod incelemeleri için aşağıdaki prosedürler var . Şimdiye kadar bizim için iyi çalıştı ve özellikle adam-saat açısından çok zaman verimli olduğunu gördük. İncelemelere ayrılan özel bir zamanımız yok. Bagajdaki her taahhüt veya birleşme gözden geçirilmelidir ve gözden geçirenin tamamlaması için gereken süre gerekir.

Düzenleme: Zaman alır, elbette, değişikliğin büyüklüğüne bağlıdır. Küçük özellikler ve hata düzeltmeleri birkaç dakika sürebilir. Sistemin birçok parçasını etkileyen büyük yeni özelliklerin, yeniden düzenlemelerin veya değişikliklerin gözden geçirilmesi yarım gün, sonuç olarak ortaya çıkan tüm sorunları ele almak için bir gün daha sürebilir.

Bu sistemin çalışması için gövdeye sık sık bağlı olmak çok önemlidir, böylece değişiklikler yönetilebilir boyuttadır. Birinin kodunu bir yıllık kodunu gözden geçirmeniz gerektiğinde bu duruma sahip olmak istemezsiniz.

Çalışmalar ile ilgili olarak, Akıllı Ayı yazılımı size ücretsiz olarak Akran Kodu İncelemesinin En İyi Tutulan Sırları adlı küçük bir kitap gönderecektir . Kod incelemesinin çeşitli yönleri hakkında, ne kadar zaman almaları ve ne kadar etkili olduklarına dair çalışmalar da dahil olmak üzere bir dizi makalesi vardır.

Projemizde, sistemdeki her önemli değişiklik ekip lideri veya yeni modülün ana "tüketicisi" olacak başka bir geliştirici ile birlikte incelenir. Skype'ta konuşuyoruz ve Emacs'ta Rudel kullanıyoruz (işbirlikçi düzenleme için bir eklenti, temel olarak birkaç kullanıcının aynı dosyayı canlı olarak düzenlemesine izin veriyor) veya TypeWith.me (Piratepad) veya birimiz ekranını skype'ta paylaşıyor.

Bunu ölçmek zordur, çünkü yeni görünümler, sayfalar vb. Yeni modülleri, büyük güncellemeleri ve yeniden düzenlemeleri inceliyoruz. Büyük değişikliklere gelince, kod incelemesi% 10 ila% 30 zaman alabilir, ancak buna değer.

İki programcı aynı dosyayı aynı anda düzenlediğinde, sadece aynı bilgisayarda oturmakla kalmayıp, omzunun arkasında oturmanın olağan ofis uygulamasından çok daha iyi olduğunu söyleyebilirim.

Adlandırma kuralları ve kapsam hataları gibi basit şeyler için kendi veya açık kaynak otomatik araçlarımızı (jslint, pylint, pyflakes, pep8) kullanıyoruz. Ve taahhütleri ve itmeleri sınırlamıyoruz: çok kolay dallanma ve birleşme olan Mercurial kullanıyoruz (söylemeliyim, Git'ten daha kolay). Hatalar bir kod inceleme meselesi değildir.

Değişikliklerin ve yeni şeylerin açıklandığı ekip toplantıları yapıyoruz, ancak orada herkes gerçekten dikkat etmiyor. Muhtemelen biraz daha kod incelemeleri yapmalıyız.

Bunun doğru ya da yanlış cevabı yok. Ancak benden önce önerdiği gibi - kod incelemesi harici bir ekip üyesi tarafından yapılırsa [şiddetle tavsiye edilir yöntem] geliştirme çabasının yaklaşık% 30 ila% 35'i kadar olabilir . Ancak bu, geliştirme ekibinin bir parçası olan [önerilmez] dahili bir proje ekibi üyesi tarafından yapılırsa, bu, geliştirme çabası için harcanan sürenin yaklaşık% 20'si içinde tamamlanabilir .

Not: Başka bir şey ararken bu iş parçacığına rastladım ve burada bir miktar değer ekleyebileceğimi düşündüm. Btw, yukarıdaki tüm bu çaba tahmini, birden fazla projede katılım yöneticisi olarak iş deneyimime dayanıyor. Umarım yardımcı olur.

Her organizasyon ve kod tabanı farklıdır, bu nedenle endüstri çapında bir değer elde etmek zordur.
Gerçekten ciddiyseniz metrikleri toplamaya başlamalısınız. Yani yeniden inceleme de dahil olmak üzere tatmin edici bir şekilde yapılana kadar kod incelemesini yapın. Bunu bir veritabanında toplamaya başlayın (LOC, kod karmaşıklığı, programlama dili, zaman vb.). Ardından, test sırasında hata oranınızla ilgili metrikleri de toplayın. Bu kod incelemesi azaltabildiği sürece kendi başına ödeme yapmalısınız. Kusur testten geri gelirse, hataları düzeltmek için ne kadar zaman harcandığına dair metrikler toplayın. Bu verileri kuruluşunuzda oluşturun, taban çizgileri oluşturun ve oldukça doğru bir şekilde tahmin edebilirsiniz. Daha fazla öğrenmeye yönelik terimler Kalite Maliyeti ve Düşük Kalite Maliyeti'dir.

Tek uyarı, bunun bürokratik hale gelmeye başlaması ve organizasyon kültürüne bağlı olmasıdır.