Yazılım Kalitesi için Hedef Metrikleri [kapalı]

Yazılım ürünlerinde ölçülebilen çeşitli kalite türleri vardır, örneğin amaca uygunluk (örn. Son kullanım), sürdürülebilirlik, verimlilik. Bunlardan bazıları biraz öznel veya alana özgüdür (örn. İyi GUI tasarım ilkeleri kültürler arasında farklı olabilir veya kullanım bağlamına bağlı olabilir, askeriye karşı tüketici kullanımını düşünebilir).

İlgilendiğim, türlerin ağı (veya grafiği) ve bunların birbiriyle ilişkili olmasıyla ilgili daha derin bir kalite biçimi, yani her bir türün ne anlama geldiği, uygun bir şekilde ilgili açıkça tanımlanabilir bağlantı bağlantıları kümeleri var mı? katmanlı mimari, ya da tersine büyük bir 'top' tipi referanslar ('monolitik' kod) vardır. Ayrıca, her tür ve / veya yöntemin boyutu (örneğin, Java bayt kodu veya .Net IL miktarıyla ölçülür), daha karmaşık / sürdürülebilir olarak ayrıştırılmak yerine monolitik kod blokları olarak büyük karmaşık algoritmaların nereye uygulandığına dair bazı belirtiler vermelidir. parçaları.

Bu tür fikirlere dayanan bir analiz, kalite için en azından bir vekil olan metrikleri hesaplayabilir. Yüksek ve düşük kalite arasındaki kesin eşik / karar noktaları sübjektif olduğundan şüphelenirim, örneğin sürdürülebilirlik ile insan programcıların sürdürülebilirliğini kastediyoruz ve bu nedenle fonksiyonel ayrışma insan aklının nasıl çalıştığı ile uyumlu olmalıdır. Bu nedenle, olası tüm senaryolarda olası tüm yazılımları aşan, matematiksel olarak saf bir yazılım kalitesi tanımı olup olmadığını merak ediyorum.

Ayrıca, bunun tehlikeli bir fikir olup olmadığını merak ediyorum, eğer kalite için nesnel vekiller popüler hale gelirse, iş baskıları geliştiricilerin bu metrikleri genel kalite pahasına (vekiller tarafından ölçülmeyen kalite yönleri) pahasına takip etmelerine neden olacaktır.

Kaliteyi düşünmenin bir başka yolu entropi açısındandır. Entropi, sistemlerin düzenden düzensiz durumlara dönme eğilimidir. Şimdiye kadar gerçek bir dünyada, orta ila büyük ölçekli yazılım projesinde çalışan herkes, kod tabanının kalitesinin zaman içinde bozulma derecesini takdir edecektir. İş baskıları genellikle yeni işlevselliğe (kalitenin kendisinin, örneğin aviyonik yazılımda ana satış noktası olduğu yerler) odaklanan değişikliklere ve regresyon sorunları ve iyi uymadığı durumlarda 'ayakkabı-horning' işlevselliği ile kalitenin aşınmasına neden olur. kalite ve bakım perspektifi. Peki, yazılımın entropisini ölçebilir miyiz? Ve eğer öyleyse, nasıl?

Bu tehlikeli bir fikir. "Objektif" kalite vekilleri doğrudan yönetim ödüllerine yol açar ve geliştiriciler bu metrikleri gerçek kalite pahasına takip ederler.

Bu istenmeyen sonuçların yasasıdır.

Kalite - önemli olsa da - yazılımın sadece küçük bir yönüdür. Yazılımın yarattığı işlevsellik ve değer kaliteden çok daha önemlidir.

Tüm metrikler, metriği optimize etmek için etkinliğe yol açar. Bunun da, gerçekten sevmeyebileceğiniz sonuçları vardır.

Yazılım çok karmaşık. Ne kadar karmaşık olduğunu anlamak zor.

Birim test kodu kapsamı gibi "açık" şeyler bile zaman kaybına neden olabilir. % 100'e ulaşmak aslında test edilen önemsiz koddan daha karmaşık testler oluşturulmasını gerektirebilir. % 100 kapsamına ulaşmak kabul edilemez bir maliyet içerebilir. [Önemsiz, küçük, nadiren kullanılan kodların alternatifi muayene ile test edilmesidir. Ancak bu,% 100 metrik oyununa uymuyor.]

Başka bir örnek, Siklomatik Karmaşıklıktır. Kod kalitesinin en iyi ölçülerinden biridir. Ancak, daha büyük bir fonksiyondan daha fazla okunması (ve bakımı daha zor) birçok küçük fonksiyon yaratarak oynanabilir. Çok okunabilir olmayabileceğini ancak karmaşıklık eşiğini karşıladığını kabul ettiğiniz kod incelemelerine girersiniz.

Ayrıca, bunun tehlikeli bir fikir olup olmadığını merak ediyorum, eğer kalite için nesnel vekiller popüler hale gelirse, iş baskıları geliştiricilerin bu metrikleri genel kalite pahasına (vekiller tarafından ölçülmeyen kalite yönleri) pahasına takip etmelerine neden olacaktır.

Bingo ve bu konuda "eğer" yok. Buna "Ölçüm Disfonksiyonu" denir ve Joel birçok kez gözlemlenmiş ve yazılmıştır .

Bu, bu tür metriklerin işe yaramaz olduğu anlamına gelmez, sadece teşvikleri veya politikaları açıkça bu tür proxy ölçümlerine dayandırmamak gerekir. Kaliteyi artırmak istiyorsanız, çok kötü bir değere sahip bir proxy metriği muhtemelen başlamak için iyi bir noktadır. Ancak, tüm metriklerinizin büyük değerlere sahip olması nedeniyle kalitenin iyi olduğu sonucuna varamazsınız.

İlgilendiğim, türlerin ağı (veya grafiği) ve bunların birbiriyle ilişkili olmasıyla ilgili daha derin bir kalite biçimi, yani her bir türün ne anlama geldiği, uygun bir şekilde ilgili açıkça tanımlanabilir bağlantı bağlantıları kümeleri var mı? katmanlı mimari, ya da tersine büyük bir 'top' tipi referanslar ('monolitik' kod) vardır.

Bu, fan girişi ve fan çıkışı gibi geliyor. Fan girişi, belirli bir modülü çağıran modül sayısını ve fan çıkışı, belirli bir modül tarafından çağrılan modül sayısını sayar. Kullanılacak bir uyarı işareti, büyük bir fan girişi ve büyük bir fan çıkışı olan modüller olabilir, çünkü bu zayıf tasarımı ve yeniden düzenleme veya yeniden tasarım için önemli bir hedefi gösterebilir.

Ayrıca, her tür ve / veya yöntemin boyutu (örneğin, Java bayt kodu veya .Net IL miktarıyla ölçülür), daha karmaşık / sürdürülebilir olarak ayrıştırılmak yerine monolitik kod blokları olarak büyük karmaşık algoritmaların nereye uygulandığına dair bazı belirtiler vermelidir. parçaları.

Basit bir ölçüm kod satırları olacaktır. Bunu, tüm proje boyunca toplam kod satırlarına ve modül başına kod satırlarına ayırabilirsiniz (belki de farklı boyut modülleri kullanarak). Bunu, belirli modülleri incelemeniz gerektiğini belirten bir uyarı göstergesi olarak kullanabilirsiniz. Yazılım kalitesi ölçümleri ve metrikleri üzerine bir kitap, hata oranları ve modül boyutu arasındaki ilişkinin eğrisel olduğunu gösteren bir çalışmayı tartışıyor, burada KSLOC başına ortalama kusur 175 ve 350 SLOC arasında bir boyuta sahip modüllerle geliyor.

Biraz daha karmaşık bir şey, bir sistemin test edilebilirliğini, anlaşılabilirliğini ve sürdürülebilirliğini göstermek için tasarlanmış olan siklomatik karmaşıklık olacaktır. Siklomatik karmaşıklık, bir uygulama veya modül üzerinden bağımsız yolların sayısını sayar. Test sayısı ve dolayısıyla testleri üretmek ve yürütmek için gereken çaba siklomatik karmaşıklıkla güçlü bir şekilde ilişkilidir.

Yüksek ve düşük kalite arasındaki kesin eşik / karar noktaları sübjektif olduğundan şüphelenirim, örneğin sürdürülebilirlik ile insan programcıların sürdürülebilirliğini kastediyoruz ve bu nedenle fonksiyonel ayrışma insan aklının nasıl çalıştığı ile uyumlu olmalıdır.

Durumun bu olduğundan emin değilim.

Örneğin, bir insanın çalışma belleğinin sadece 7 artı / eksi 2 nesne tutabileceğini gösteren araştırmalar yapılmıştır . Bu muhtemelen fan girişi ve fan çıkışı ölçümü için ilgi çekicidir - eğer bir modülde çalışıyorsam ve ~ 7'den fazla modüle bağlıysa, muhtemelen bunların tam olarak ne olduğunu takip edemeyeceğim diğer modüller kafamda.

Ayrıca, siklomatik karmaşıklık gibi metriklerle ilgili kusurları ilişkilendirmek için de çalışmalar yapılmıştır. Sisteminizdeki hataları en aza indirmek istediğinizden, yüksek siklomatik karmaşıklık ile tanımlandığı gibi, daha fazla çaba testi veya yeniden düzenleme gerektiren noktaları belirleyebilirsiniz.

Ayrıca, bunun tehlikeli bir fikir olup olmadığını merak ediyorum, eğer kalite için nesnel vekiller popüler hale gelirse, iş baskıları geliştiricilerin bu metrikleri genel kalite pahasına (vekiller tarafından ölçülmeyen kalite yönleri) pahasına takip etmelerine neden olacaktır.

Herhangi bir ölçüm veya metrikte durum böyledir. Sistemi anlamak ve bilinçli kararlar vermek için kullanılmaları gerekir. "Ölçemediklerinizi yönetemezsiniz" ifadesi akla geliyor. Yüksek kaliteli yazılım istiyorsanız, bu kaliteyi değerlendirmek için bazı ölçümlere ve metriklere ihtiyacınız vardır. Ancak, bunun bir ters tarafı var. Yalnızca sayılarla yönetemezsiniz. Rakamları bilinçli kararlar vermek için kullanabilirsiniz, ancak sadece sayılar böyle söylediği için karar veremezsiniz.

İlgilendiğiniz birçok nitelik için metrik veya proxy var:

1. Kod satırları
2. Fan girişi, fan çıkışı
3. 1000 kod satırı başına hata oranı
4. Cyclomatic karmaşıklık
5. Kod kapsamı
6. Karar noktası kapsamı
7. Bakım faaliyetleri ile giderilen / ortaya çıkan hataların oranı
8. İşlev noktası analizi

Tüm bu öğelerle ilgili bazı sorunlar var:

1. Metriği optimize etmek için yapılan çalışmalar - evrensel bir eğilim; Metriklerden herhangi biri, ekipler veya bireyler için değerlendirme veya ödüllendirme için temel olarak kullanılıyorsa, büyük ölçüde şiddetlenir.
2. Bağlamdan bağımsız hiçbir metriğin farkında değilim. Bu, mağazalar arasında hiçbir zaman karşılaştırmanın mümkün olmadığı anlamına gelir - sadece mağazalarda, zamanla. Bu tür karşılaştırmalardan kaynaklanan metrikler hala değerlidir - "kodu bir yıldan daha önceye göre daha doğru mu üretiyoruz?"

Bu konuların toplam etkisi, bunlar gibi metriklerin yalnızca TKY, kalite güvencesi (kontrol değil), sürekli iyileştirme, kaizan vb. Gibi daha geniş bir kültür içinde değerli olmalarıdır. Her iki kültürün unsurlarını tanımlamak gerekir. ve nasıl değişmesi gerektiği. Bunların tanımına sahipseniz, bu gibi metrikler, kodun kalitesini, çalışma uygulamalarını, üretkenliği vb. İyileştirmeye yardımcı olan temel araçlar haline gelir. Bu daha geniş bağlam olmadan metrikler, metriği optimize etmek için iş oluşturur; üretkenliği artırmak ve maliyetleri azaltmak için fasulye sayacının aracı olacak; ve geliştirme personeli tarafından oynanacak bir engel haline gelecektir.

Metriklere takıntılı olabilirsiniz veya karşılayabileceğiniz en iyi insanlara, araçlara, mühendislik uygulamalarına ve KG'ye takıntılı olabilirsiniz. 'Rasgele tarafından kandırılmış' okuyan ve sayıları olan güzel biçimlendirilmiş raporlardan çok otomatikleştirmeyi seven birkaç paranoyak QA dehasına sahip olmaktan çok mutlu olurum.

Metriklerle ilgili bu temel sorun var.

Önerilen metriklerin hemen hemen tamamı, gerçek dünyada, gerçek kodda, ham SLOC (kaynak kod satırları) ile güçlü veya çok güçlü bir şekilde ilişkili olduğu gösterilmiştir.

Halstead'in metriklerini 1970'lerde öldüren buydu. (Bir gün, yaklaşık 1978'de, Halstead'in metrikleri hakkında yeni bir doktora yaptığı bir konuşma üzerine oturdum, bunu işaret etti.)

Daha yakın bir zamanda, McCabe'nin siklomatik karmaşıklığının, ham SLOC ile çok güçlü bir şekilde ilişkili olduğu gösterilmiştir; bu, McCabe'nin metriği bize yararlı bir şey söylerse, çalışmayı yapan kişinin yüksek sesle merak ettiğini belirtti.

Onlarca yıldır büyük programların küçük sorunlardan daha fazla sorun yaşandığını biliyoruz. On yıllardır büyük altyordamların küçük olanlardan daha fazla hataya sahip olduklarını biliyoruz. Bunu bize bildirmek için neden gizli metriklere ihtiyacımız var, bir masaya yayılmış dört yazıcı sayfasına bakarken yeterince ikna edici olmalı?

Buradaki diğer cevaplar göz önüne alındığında, bu küçük cevapla kendimi aptalca hissediyorum. Java'da yöntemleri ne kadar kokuştuklarına göre sıralamaya çalışan Crap4j'ye bir göz atın . (Proje terk edilmiş görünüyor.)

Siklomatik karmaşıklık ve test kapsamının bir kombinasyonunu kullanır. Diğer tüm metrikler gibi, oynanabilir.