Kod inceleme sürecinin etkinliği nasıl belirlenir?

Kuruluşumuzda bir kod inceleme süreci başlattık ve iyi çalışıyor gibi görünüyor. Ancak, zaman içinde sürecin etkinliğini ölçmek istiyorum, yani kod temiz olduğu için biz hataları bulamıyor muyuz ya da insanlar sadece hataları almak değil mi?

Şu anda etkin bir tam otomatik test sürecimiz yok. Öncelikle manuel test uyguladığımızdan, kod inceleme sürecinin çalıştığından emin olmak için bu aşamada bulunan kusurlara güvenemeyiz.

Bu sorunla daha önce karşılaşan biri var mı veya kod incelemelerini ölçmede neyin işe yaradığına dair düşünceleri var mı?

Kod incelemelerinden toplanabilecek, bazıları projenin yaşam döngüsü boyunca bile uzanan bir dizi metrik vardır.

Toplamayı tavsiye edeceğim ilk metrik, kusur giderme etkinliği (DRE) . Her hata için, hatanın hangi aşamada uygulandığını ve hangi aşamada kaldırıldığını tanımlarsınız. Kullandığınız çeşitli hata algılama tekniklerinin hepsi aynı anda değerlendirilir, bu nedenle gereksinimler incelemeleri, tasarım incelemeleri, kod incelemeleri, birim testleri için eşit olarak geçerlidir. , ve bunun gibi. Özellikle kod aşamasında yakalanan hataların sayısıyla ilgilenirsiniz, çünkü bu muhtemelen birim testlerinizi ve kod incelemelerini kapsayacaktır. Kod aşamasındaki birçok hata, entegrasyon test aşamasına veya hatta alana geçiyorsa, kodlama sonrası uygulamalarınızın değerlendirilmesi gerektiğini bilirsiniz.

Çeşitli toplantı metrikleri de alakalı olacaktır. Bunlar hazırlık zamanı, toplantı zamanı, okunan kod satırları, incelemede bulunan kusurlar vb. Bu verilerden bazı gözlemler yapılabilir. Örnek olarak, gözden geçirenleriniz, incelemeye hazırlanırken kodu okumak için çok fazla zaman harcıyorlar, ancak çok az sorun buluyorlardı. DRE verileriyle birleştiğinde, entegrasyon testinde veya sahada kusurlar test ediliyorsa, ekibinizin sorunları bulabilmek için inceleme tekniklerine odaklanması gerektiği sonucuna varabilirsiniz. Bir başka ilginç not, toplantıda okunan kod satırları (veya başka bir boyut ölçümü), toplantının zamanına kıyasla olacaktır. Araştırmalar, tipik bir kod incelemesinin hızının saatte 150 satır kod olduğunu bulmuştur.

Bu metriklerden herhangi birinde, süreç üzerindeki etkilerini anlamak önemlidir. Neden-çünkü , Beş Neden veya Ishikawa diyagramları gibi teknikler kullanılarak kök neden analizi, kod incelemelerinin (veya başka bir kalite geliştirme tekniğinin) neden etkili olduğunu belirlemek için kullanılabilir.

Ayrıca , Ganssle Grubu'nun denetimleri hakkında bu makaleyle ve Crosstalk'taki Capers Jones'un Arıza Potansiyeli ve DRE hakkında bir makalesi de ilginizi çekebilir .

Kod incelemesinin , testin yakalanabileceği veya yakalanmayabileceği oldukça gizli olan problemleri alacağı büyük ölçüde doğrudur . Ancak, bence gerçekten kararlı (neredeyse hatasız) bir koda sahip olabilirsiniz, ancak yine de son derece okunamaz veya oldukça bakımsız olacak şekilde yazılmıştır. O kod incelemesi kaynaklanıyor olabilir Yani DEĞİL kodunda aslında hiçbir gerçek sorunlar varsa hataları bulmak.

Söyledikten, gerçekten sormak istiyorum, neden bir kod inceleme yapmak istersiniz? Önemli olmasının basit nedeni, kodun daha okunabilir, bakımı kolay ve geliştirilebilir olması için geliştirilmesidir. Birçok kişi daha temiz kodları okuyabilmeli ve ondan anlam çıkarabilmelidir. Bu bağlamda, kod inceleme sürecinin en basit amacı temiz kod üretmektir. Etkililiğin ölçüsü, kodun ne kadar temiz olduğudur.

Ölçülebilir bir etkinliğe sahip olmak istediğiniz için - işte önereceğim şey:

1. Yeniden çalışma miktarıyla ilgili metrik - Belirli bir modül / nesne / iş öğesinde yeniden çalışmanın uygulanma süresi, kodun sürdürülebilirlik açısından ne kadar zayıf olduğunun bir ölçüsüdür . Etkili kod incelemesi uygulandığında, aynı modülde yeniden çalışma talebini ne sıklıkta azaltabiliriz?

2. Her değişiklik talebinin gerçekleştirdiği değişiklik miktarıyla ilgili metrik. Bir değişiklik isteği her gerçekleştiğinde - zayıf faktörlü bir kod her zaman daha fazla sayıda modülün etkilenmesini sağlar. Bir önlem muhtemelen bir kod incelemesinden sonra - a geçmişte benzer bir değişiklik talebi için bu tür bir değişiklik yayılmasının azalması olduğunu gösterecektir ?

3. Bir değişiklik isteğinin yanıtlanabileceği ortalama hızla ilgili metrik. Kod daha temiz olduğunda - daha hızlı ve daha iyi, gerekli değişikliklere cevap vermektir. Kod inceleme sürecinde temizlendikten sonra, benzer boyut talebini yanıtlamada herhangi bir hız bulduk.

Kesin ölçü birimleri koymuyorum - muhtemelen bu yaklaşımdan bu konuda daha doğru önlemler alabilirsiniz. Yukarıdaki yaklaşımlarda bu konuda daha fazla uzatma formalizmi olabilir.

Temel olarak, benim açımdan kod inceleme sürecinin tanımladığı hata sayısına bakmak yerine; etkinliği, kod incelemesinin kodu daha temiz, daha yalın ve bakımı kolay bir duruma getirip getiremeyeceği açısından ölçmeliyiz; Dolayısıyla, gelecekte benzer değişiklik taleplerinin yanıtlanmasının daha verimli hale geldiğini görürsek, bu etkinliği ölçebiliriz.