it-swarm.dev

Kaynak kod için yararlı metrikler nelerdir?

Kaynak kod için yakalanacak yararlı metrikler nelerdir?

Örneğin (Yürütülebilir mi?) Kod Satırı veya Siklomatik Karmaşıklık gibi metrikler kalite güvencesine nasıl yardımcı olabilir veya genel olarak yazılım geliştirme süreci için nasıl faydalıdır?

33
cschol

"Kod satırlarına göre yazılım verimliliğini ölçmek, bir uçaktaki ilerlemesini ağırlığına göre ölçmek gibidir. - Bill Gates

30
chrisaycock

Jeff'in konuyla ilgili yayınlarına bir göz atın:

Metrik Hizmetçiden Bir Ziyaret

Yazılım Mühendisliği: Ölü mü?

Yazılım metrikleriyle yakından ilişkili, Joel'ten de eski ama iyi bir yazı var ve okumasını şiddetle tavsiye ediyorum: Econ 101 Yönetim Yöntemi

Kilit nokta, benim için Jeff'ten alıntı: "Metriklerin sorumlu kullanımı, ilk etapta bunları toplamak kadar önemlidir."

12
Machado

Kod metrikleri hakkında beni şaşırtan şey, daha fazla yapılmamasıdır. Çoğu şirket, çalışanlarının, tedarikçilerin ve sistemlerinin etkinliğini rapor eder, ancak hiç kimse kod hakkında rapor vermek istemiyor gibi görünmektedir. Daha fazla kod satırının bir yükümlülük olduğunu ancak kodunuzun ne yaptığının daha önemli olduğunu belirten cevapları kesinlikle kabul edeceğim.

Kod Satırı: 'Dediğim gibi, bu hayati bir ölçümdür ve en ciddiye alınmalıdır, ancak her seviyede. İşlevler, sınıflar, dosyalar ve arabirimler, uzun vadede bakımı zor ve maliyetli olan her şeyi yapma kodunu gösterebilir. Toplam kod satırlarını bir sistemin yaptığıyla karşılaştırmak son derece zordur. Birçok şey yapan bir şey olabilir ve bu durumda birçok kod satırı olacaktır!

Karmaşıklık: Bu ölçüm, üzerinde çalışmadığınız kod tabanlarında yapmak için iyidir ve sorunlu alanların nerede olduğu konusunda size iyi bir gösterge verebilir. Yararlı bir fıkra olarak kendi kod tabanlarımdan birinde karmaşıklığı ölçtüm ve en yüksek karmaşıklık alanı, değiştirmem gerektiğinde en çok zaman harcadığım alan oldu. Karmaşıklığı azaltmaya yönelik çalışma, bakım süresinde büyük bir azalmaya neden oldu. Yönetim bu ölçümleri elinde bulundursaydı, bir sistemin belirli alanlarının yinelemelerini veya yeniden tasarımlarını yeniden planlamayı planlayabilirlerdi.

Kod çoğaltma: Bu benim endişelendiğim kadarıyla çok önemli bir ölçüm. Kod çoğaltma çok kötü bir işarettir ve bir sistemin tasarımının düşük düzeylerindeki derin sorunlara veya kopya yapıştırma olan geliştiricilere, uzun vadede büyük sorunlara ve sürdürülemeyen sistemlere işaret edebilir.

Bağımlılık Grafikleri Kötü bağımlılıklar ve dairesel bağımlılıklar bulmak kodda önemli bir ölçümdür. Bu neredeyse her zaman gözden geçirilmesi gereken yanlış bir üst düzey tasarıma işaret eder. Bazen bir bağımlılık bir sürü gereksiz başkalarını emebilir, çünkü birisi finans hesaplarını yapmak için bir e-posta kütüphanesinde addNumber kullanıyor. E-posta kitaplığı değiştirildiğinde ve finans kesildiğinde herkes şok olur. Eğer her şey bir şeye bağlıysa, bakımı zor ve kötü tasarlanmış kütüphaneleri de işaret edebilir.

İyi bir ölçüm size her zaman bir sistemin her özelliğinin az yer kapladığını söyleyecektir. Daha az bağımlılık, daha az karmaşıklık, daha az çoğaltma. Bu gevşek bağlantıya ve yüksek kohezyona işaret eder.

11
Tjaart

Bu "kaynak kodu metrikleri" EVER die bok olmaz mı?

Ham kaynak kod satırları (SLOC) en eski, en kolay, en temel metriktir.

Halstead başlangıçta bir sürü metrik önerdi. Pek çok insan, bazı spoilsport bariz bir çalışma yapana kadar çok eğlenceli ölçüm programları yazıyordu ve her bir Halstead metriğinin SLOC ile güçlü bir şekilde doğrudan ilişkili olduğunu gösterdi.

Bu noktada Halstead'in metrikleri terk edildi, çünkü SLOC her zaman daha kolay ölçülüyor.

8
John R. Strohm

Kalite güvencesi için kaynak kodu metrikleri iki hedefi hedefler:

  • içinde daha az hata bulunan kod yazma
  • kolay bakım için kod yazma

Her ikisi de mümkün olduğunca basit bir şekilde kod yazılmasına yol açar. Bunun anlamı:

  • kısa kod birimleri (fonksiyonlar, yöntemler)
  • her birimdeki birkaç öğe (bağımsız değişkenler, yerel değişkenler, deyimler, yollar)
  • az çok karmaşık olan diğer birçok kriter (Wikipedia'da Yazılım ölçümü konusuna bakın).
8
mouviciel

Bildiğim kadarıyla, bulunan hataların sayısı doğrudan kod satırları (muhtemelen karmaşası), modulo dili, programcı ve etki alanı ile ilişkilidir.

Hatalarla iyi ilişkilendirilmiş başka basit ve pratik bir metrik bilmiyorum.

Yapmak istediğim bir şey, üzerinde çalıştığım farklı projelerin numaralarını çalıştırmaya başlamak - Test Kapsamı :: kLOC ve sonra bir korelasyon olup olmadığını görmek için "algılanan kalite" konusunu tartışmak.

7
Paul Nathan

Metrikler yalnızca aldığınız cevaplarla ne yapacağınızı biliyorsanız faydalıdır. Temelde bir yazılım metriği bir termometre gibidir. Bir şeyi 98.6 ° F'de ölçmeniz, normal sıcaklığın ne olduğunu bilmeden hiçbir şey ifade etmez. Yukarıdaki sıcaklık vücut ısısı için iyidir, ancak dondurma için gerçekten kötüdür.

için yararlı olabilecek yaygın metrikler şunlardır:

  • Keşfedilen hatalar/hafta
  • Çözülen hatalar/hafta
  • # Gereksinimler tanımlandı/serbest bırakıldı
  • # Gereksinimler uygulandı/serbest bırakıldı

İlk iki eğilim trendleri ölçüyor. Hataları onarabileceğinizden daha mı hızlı buluyorsunuz? İki olası sonuç: belki hataları gidermek için daha fazla kaynağa ihtiyacımız var, belki yakalayana kadar yeni özellikler uygulamayı bırakmalıyız. İkinci ikisi, ne kadar yakın olduğunuza dair bir resim sağlar. Çevik takımlar buna "yanmak" grafiği derler.

Siklomatik Karmaşıklık ilginç bir metriktir. Temel konseptinde, bir işlev/yöntemdeki benzersiz yürütme yollarının sayısıdır. Birim test ağır ortamında bu, her yürütme yolunu doğrulamak için gereken test sayısına karşılık gelir. Bununla birlikte, 96 Döngüsel Karmaşıklığı olan bir yönteminiz olması, mutlaka buggy kodu olduğu anlamına gelmez - veya makul bir güven sağlamak için 96 test yazmanız gerektiği anlamına gelmez. Bu karmaşık bir şey oluşturmak için oluşturulan kod (WPF veya ayrıştırıcı jeneratörleri aracılığıyla) nadir değildir. Bir yöntemin hata ayıklaması için gereken çaba düzeyi hakkında kabaca bir fikir verebilir.

Alt satır

Aldığınız her ölçümün aşağıdakileri tanımlaması gerekir veya işe yaramaz:

  • "Normal" in ne olduğunun anlaşılması. Bu, projenin ömrü boyunca ayarlanabilir.
  • Bir tür işlem yapmanız gereken "normal" dışında bir eşik.
  • Eşik aşıldığında kodla başa çıkma planı.

Aldığınız metrikler projeden projeye değişebilir. Projelerde kullandığınız birkaç metriğiniz olabilir, ancak "normal" tanımı farklı olacaktır. Örneğin, bir proje haftada ortalama 5 hata bulduysa ve yeni proje haftada 10 hata keşfediyorsa, bir şeyin yanlış olduğu anlamına gelmez. Test ekibi bu sefer daha titiz olabilir. Ayrıca, "normal" tanımı projenin ömrü boyunca değişebilir.

Metrik sadece bir termometredir, onunla ne yaptığınız size bağlıdır.

7
Berin Loritsch

Kaynak kodu bir varlık değil bir yükümlülüktür. Bunu göz önünde bulundurarak, kod satırlarını ölçmek bir ev inşa ederken harcanan dolarları izlemeye benzer. Bütçe altında kalmak istiyorsanız yapılması gerekir, ancak günde 1000 dolar harcamanın günde 50 dolar harcamaktan daha iyi olduğunu düşünmezsiniz; bu para için evin ne kadarının inşa edildiğini bilmek istersiniz. Bir yazılım projesindeki kod satırları ile aynıdır.

Kısacası, kaynak kodunun kendi başına ölçülmesi yararlı olmadığından kaynak kod için yararlı bir metrik yoktur.

6
Larry Coleman

Kaynak kodu basitçe bir dizi, seçim ve tekrar kombinasyonudur. Eğer makul bir şekilde üretmeyi bekleyebileceğimiz en uygun yazılım parçasını tanımlasaydım aşağıdaki gibi olurdu. İşi yapmak için gerekli olan ve değişikliklere dayanabilecek kadar esnek olan en az kod satırını kullanan yaklaşık% 100 test kod kapsamına sahip yazılım.

4
Xenohacker

Performansı ölçmek için KLOC sayısının neden işe yaramaz (hatta zararlı) olduğunu gösteren bir fıkra.

Yıllar önce, ekiplerin ve bireylerin performansının tek ölçüsü olarak KLOC sayılarını kullanan büyük bir projede (şirketimizde 70+ kişi, müşterimizde 30+ kişi daha) çalıştım.

Y2K çabalarımız için (size ne kadar zaman önce olduğunu söyler :)) ekibimin sorumlu olduğu kodun büyük bir bölümünü yaptık. Serbest bırakılması için 5 kişi için 3 aylık kötü bir çalışma değil, yaklaşık 30.000 satır kod yazdık. Ayrıca, özellikle yeni kodla birlikte, 3 aylık bir çalışma için çok iyi bir iş olan 70.000 satır kod daha kazıdık.

Çeyrek için sonuç: -40.000 satır kod. Üç aylık dönemi izleyen performans incelemesinde, şirketten çeyrek başına üretilen 20.000 satırlık kod üretkenlik gereksinimlerimizi karşılayamadığı için resmi bir kınama aldık (sonuçta, araçlarda -40.000 satırlık kod ürettiğimizi gösterdi) hepimizin düşük performans göstermesi ve promosyonlar, eğitim, ücret artışı vb. için atlanmasıyla sonuçlanmamıza neden olacaktı. Proje yöneticisi ve KG ekibi müdahale etmedi ve kınama işlemini devirip yerine bir övgü aldı.

Birkaç ay sonra (bu tür şeyler zaman alır) şirketin verimlilik standartlarını gözden geçirdiği ve fonksiyon noktası analizine dayalı yeni bir sistem oluşturmak için bir uzman ekibi tuttuğu söylendi.

4
jwenting

Hiç kimsenin bahsetmediğim Birim Testleri Beyanı/Karar Kapsamı (birim testler tarafından kullanılan kodun yüzdesi).

Kod kapsamı, uygulamanın yüzde kaçının felaketle sonuçlanmadığını bilmeniz açısından yararlıdır; yararlılığının geri kalanı ile birim testlerin kalitesine bağlıdır.

2
StuperUser

Bunlar ilerleme açısından çok yararlı değil mutlak metrikleri, ancak kodun durumu hakkında genel bir fikir vermek için kullanılabilir.

Özellikle Siklomatik Karmaşıklık Belirli bir kod tabanının ne kadar modüler hale getirildiğinin görselleştirilmesinde yararlı buldum. Modül başına kaynak sayısının düşük olduğu ve çok sayıda modül olduğu için genellikle düşük bir karmaşıklık istiyorsunuz.

1
user1249

Taahhüt ne kadar küçük olursa, genellikle o kadar iyidir. Bu, SCM araçlarıyla ilgilidir, kendi başına kodlamakla kalmaz, ancak çok ölçülebilir bir metriktir. Taahhüt ne kadar küçük olursa, her değişikliği bir atom birimi olarak görmek o kadar kolay olur; işler değiştiğinde belirli değişiklikleri ve noktaları geri almak daha kolaydır.

Hiçbir taahhüt, yapıyı bozmadığı sürece ...

1
Assaf Lavie

İşimde kod metriklerini kullandığım birçok durum var:

Kod yazarken

Günlük işimdeki en büyük ve belki de en önemli kullanım, kodumun metriklerini (diğer şeylerin yanı sıra) sürekli olarak kontrol eden Java geliştiriciler için bir araç) Checkstyle tanımladığımız bir dizi kural ve kodumun bu kurallara uymadığı yerleri işaretler.Kod geliştirdiğimde, yöntemlerimin uzun, karmaşık veya birleştiğinde gerçek zamanlı olarak geri dönmeme izin verir ve daha iyi bir şeye yeniden yansıtmayı düşünün.

Geliştiriciler hiçbir zaman tüm kurallara uymayacakları için tüm kuralları çiğnemekte serbesttirler. "Kurallar" düşünceyi teşvik etmek ve "Hey, bunu yapmanın en iyi yolu bu mu?"

KG/Kod İncelemeleri Sırasında

Genelde bir kod inceleme yaparken yaptığım ilk şey, hangi kod satırları kapsanan vurgulamaktadır bir kod kapsama aracı ile birlikte inceliyorum kodun kod kapsamını kontrol etmektir. Bu bana test kodunun ne kadar kapsamlı olduğuna dair genel bir fikir veriyor. Önemli kod iyi test edildiği sürece kapsamın% 20 veya% 100 olup olmadığını gerçekten umursamıyorum. Dolayısıyla, kapsanan yüzde biraz anlamsızdır, ancak% 0 emin olmak istediğim bir şey gibi ağrılı bir başparmak gibi gözükür.

Ayrıca, ekip tarafından kabul edilen metriklerin, eğer varsa, geliştiriciye uygun olup olmadığını veya iyileştirmenin yollarını önerebileceğimi görmek için 'kırılmış' olup olmadığını da kontrol ediyorum. Bu geliştirme metriklerinin ekibimizde yeni kod yazma konusunda üzerinde anlaşmaya varılması, kodumuzu geliştirmek için büyük yollara imza attı. Çok daha az monolitik yöntemler yazıyoruz ve tek sorumluluk ilkesi şimdi çok daha iyi.

Eski kodda trend geliştirmeler Etrafımızda geliştirmek istediğimiz birçok eski kod var. Herhangi bir zamanda metrikler oldukça işe yaramaz, ancak bizim için önemli olan, zamanla kod kapsamının artması ve karmaşıklık ve bağlantı gibi şeylerin azalmasıdır. Bu nedenle, metriklerimiz Sürekli Entegrasyon sunucumuza takılır ve doğru yolda olduğumuzu garanti etmek için zamanla bakmamızı sağlar.

Yeni bir kod tabanı ile kavramak Hiç kaynak kod metriği satırlarını kullanmak hakkında sadece bir kod üssüne bakarken aşina değilim ile. Çalıştığım diğerlerine kıyasla projenin kaba boyutunu hızlı bir şekilde ölçmemi sağlıyor. Diğer metrikleri kullanarak projenin kalitesi hakkında daha kaba bir fikir edinebilirim.

Kilit nokta, metrikleri eğilim, tartışmalar veya ileriye dönük yollar için başlangıç ​​noktaları olarak kullanmak ve bunları kesin rakamlara dini olarak yönetmemektir. Ancak, doğru kullanıldıklarında doğru kodu geliştirmenize yardımcı olabileceklerine inanıyorum.

1
Chris Knight

Sık sık dev bir C++ paketi üzerinde çalışıyorum ve Cyclomatic Complexity veya korkunç FanIn/FanOut yeniden düzenleme değerinde sorunlu kod ararken genellikle oldukça iyi kırmızı bayraklar vardır. Sorunları gidermek genellikle kod tabanının tamamında iyileştirmelere yol açar.

Tabii ki bu rakamlar sadece bakmaya değer bir ipucu olabilir. Bunu biraz zor bir eşik haline getirmek, bundan sonra bir yapıda başarısız olmak veya bir taahhüdü reddetmek saçma olurdu.

1
Benjamin Bannier

S: Kaynak kodu yakalamak için yararlı metrikler nelerdir?

İş için:

A: adam-saat sayısı

Kodlayıcı süpervizörü için:

C: Önemli değil. Bugün her şeyi yapalım

Kodlayıcının benlik saygısı için:

C: SLOC Sayısı (Kaynak Kod Satırı)

Kodlayıcının annesi için:

C: Bu yumuşak Fransız rulolarından daha fazla yiyin ve çay için

aşağıdaki yorumlarda devam etti ...

0
Genius