Kaynak kod için faydalı ölçütler nelerdir? [kapalı]

Kaynak kod için yakalamak için yararlı ölçümler nelerdir?

Örneğin (Yürütülebilir?) Kod Satırları veya Döngüsel 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?

"Yazılım üretkenliğini kod satırlarıyla ölçmek, uçaktaki ilerlemenin ağırlığını ölçmek gibidir." - Bill Gates

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

Metrik Hizmetçiden Bir Ziyaret

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

Joel'in yazdığı yazılım ölçütleriyle de ilgili eski ama iyi bir yazı var ve okunmasını şiddetle tavsiye ediyorum: Econ 101 Yönetim Yöntemi

Benim için kilit nokta şudur: Jeff'den alıntı yapmak: "Metrikleri sorumlu kullanmak, ilk etapta onları toplamak kadar önemlidir."

Kod ölçümleriyle ilgili beni şaşırtan şey, daha fazlasını yapmamaktır. Çoğu şirket, çalışanlarının, tedarikçilerinin ve sistemlerinin yürürlükte olduğu konusunda rapor verir, ancak kimse kodu rapor etmek istemez. Daha fazla kod satırının bir sorumluluk olduğunu ancak kodunuzun ne kadar önemli olduğunu belirten yanıtları kesinlikle kabul edeceğim.

Kod Satırları: Daha önce belirttiğ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 yapan kodu gösterebilir. Bir sistemin yaptığı ile karşılaştırıldığında toplam kod satırlarını karşılaştırmak sonsuz zordur. Çok şey yapan bir şey olabilir ve bu durumda birçok kod satırı olacak!

Karmaşıklık: Bu ölçüm, üzerinde çalışmadığınız kod tabanları üzerinde yapmak için iyidir ve sorunlu alanların nerede bulunduğunun iyi bir göstergesi olabilir. Yararlı bir anekdot olarak, kendi kod tabanlarımdan biri üzerindeki karmaşıklığı ölçtüm ve en yüksek karmaşıklık alanı, değiştirmek istediğimde en çok zaman harcadığım alandı. Karmaşıklığı azaltmaya yönelik çalışmak, bakım süresinde büyük bir düşüşle sonuçlandı. Eğer yönetim bu ölçümleri elinde bulundurduysa, yeniden yapılanma yinelemelerini veya sistemin belirli alanlarının yeniden tasarlanmasını planlayabilir.

Kod çoğaltma: Bu benim ilgilendiğim kadarıyla çok önemli bir ölçüm. Kod çoğaltma çok kötü bir işarettir ve ya sistemin tasarımının düşük seviyelerindeki derin sorunlara ya da kopya yapıştıran geliştiricilere uzun vadede büyük sorunlara neden olan 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 revize edilmesi gereken yanlış bir üst düzey tasarıma işaret ediyor. Bazen bir bağımlılık, gereksiz başkalarını da emebilir, çünkü birisi finans hesaplamaları yapmak için bir e-posta kütüphanesinde addNumber kullanıyor. E-posta kütüphanesi değiştiğinde ve finansman bozulduğunda herkes şok olur. Eğer her şey bir şeye bağlıysa, bakımı zor ve kötü bir şekilde tasarlanmış her şeyi kütüphaneye işaret edebilir.

İyi bir ölçüm size her zaman 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 birleşme ve yüksek uyum gösterir.

Bu "kaynak kod metrikleri" hiç ölmedi mi?

Ham kaynak kod satırı (SLOC), en eski, en kolay, en temel ölçümdür.

Halstead aslen bir sürü metrik önermişti. Bir çok sporsport bariz bir çalışmayı gerçekleştirene kadar pek çok insan çok eğlenceli yazma ölçüm programlarına sahipti ve her bir Halstead metrikinin SLOC ile doğrudan ilişkili olduğunu gösterdi.

Bu noktada, Halstead'in metrikleri terk edildi, çünkü SLOC ölçümü her zaman daha kolaydı.

Kalite güvencesi için kaynak kodu ölçümleri iki amacı hedeflemektedir:

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

Her ikisi de olabildiğince basit kod yazma yol açar. Bunun anlamı:

• kısa kod birimleri (fonksiyonlar, yöntemler)
• her birimdeki birkaç öğe (argümanlar, yerel değişkenler, deyimler, yollar)
• ve diğer pek çok kriter az ya da çok karmaşık (bkz . Wikipedia'daki Yazılım metriği ).

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şkilendirilen başka basit ve pratik bir metrik bilmiyorum.

Yapmak istediğim bir şey, üzerinde bulunduğum farklı projeler için sayıları koşmaya başlamaktır - Test Kapsamı :: kLOC ve sonra bir korelasyon olup olmadığını görmek için "algılanan kaliteyi" tartışmak.

Metrikler, yalnızca aldığınız cevaplarla ne yapacağınızı biliyorsanız yararlı olur. 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 öğrenene kadar hiçbir şey ifade etmez . Yukarıdaki sıcaklık vücut sıcaklığına iyi gelir ancak dondurma için çok kötüdür.

Yararlı olabilecek yaygın metrikler :

• Bulunan hatalar / hafta
• Hatalar çözüldü / hafta
• # Gereksinimler tanımlandı / bırak
• # Gereksinimler uygulandı / yayınlandı

İlk iki ölçü trendi. Hataları onarabileceğinden daha hızlı mı buluyorsun? İki olası sonuç: belki hataları düzeltmek için daha fazla kaynağa ihtiyacımız var, belki de yetişene kadar yeni özellikleri uygulamayı bırakmalıyız. İkinci ikisi, ne kadar yakın olduğunuza dair bir resim sunar. Çevik ekipler buna "yazma" şeması diyor.

Siklomatik Karmaşıklık ilginç bir ölçümdür. Temel konseptte, bir işlev / yöntemdeki benzersiz yürütme yolu 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, sadece 96 döngüsel karmaşıklığı olan bir yönteme sahip olmanız, mutlaka yanlış kod olduğu anlamına gelmez - ya da makul bir güven sağlamak için 96 test yazmanız gerekir. Bu karmaşık bir şey oluşturmak için oluşturulan kod (WPF veya ayrıştırıcı jeneratörler aracılığıyla) nadir değildir. Bir yöntemde hata ayıklamak için gereken çaba seviyesi hakkında kabaca bir fikir verebilir.

Alt çizgi

Yaptığınız her ölçümün aşağıdakileri tanımlaması gerekir veya faydasızdır:

• "Normal" olanın anlaşılması. Bu, proje ö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 çıkmak için bir plan.

Aldığınız ölçütler, projeden projeye büyük ölçüde değişebilir. Projeler arasında kullandığınız birkaç ölçüt olabilir, ancak "normal" tanımı farklı olacaktır. Örneğin, bir proje haftada ortalama 5 böcek keşfettiğinde ve yeni proje haftada 10 böcek keşfettiğinde, bunun mutlaka bir şeyin yanlış olduğu anlamına gelmez. Sadece bu sefer test ekibi daha titiz olabilir. Ayrıca, "normal" tanımı projenin ömrü boyunca değişebilir.

Metrik sadece bir termometredir, onunla ne yaptığınız size kalmış.

Kaynak kodu bir yükümlülük değil bir varlıktır. Bunu akılda tutarak, kod satırlarını ölçmek, bir ev inşa ederken harcanan dolarları izlemeye benzer. Bütçenin altında kalmak istiyorsanız bunun yapılması gerekiyor, ancak günde 1000 dolar harcamanın günde 50 dolar harcamaktan daha iyi olduğunu düşünmek zorunda değilsiniz; evin ne kadarının bu para için yapıldığını bilmek istersiniz. Bir yazılım projesinde kod satırlarıyla aynıdır.

Kısacası, kaynak kod için yararlı bir ölçüm yoktur, çünkü kaynak kodunu tek başına ölçmek faydalı değildir.

Kaynak kod basitçe bir dizi, seçim ve tekrarın birleşimi olduğu için. Üretmek için makul bir şekilde bekleyebileceğimiz en uygun yazılım parçasını tanımlasaydım, aşağıdaki gibi olurdu. Neredeyse% 100 test kodunu içeren yazılım, işi yapmak için gereken en az kod satırını kullanarak ve değişikliklere dayanacak kadar esnek.

KLOC sayımlarının performansı ölçmede neden faydasız (ve hatta zararlı) olduğunu gösteren bir fıkra.

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

Y2K çabamız için (size ne kadar zaman önce olduğunu söyler :)) ekibimin sorumlu olduğu kodun bir bölümünü temizledik. 5 kişi için 3 aylık bir çalışmadan değil, yaklaşık 30.000 satırlık bir kod satırı yazdık. Ayrıca, yeni bir kodla birlikte, 3 aylık bir çalışma için çok iyi bir iş olan 70.000 kod satırı daha hurdaya çıkardık.

Çeyrek için sonuç: -40.000 kod satırı. Çeyrek sonrasındaki performans incelemesi sırasında, şirketten çeyreklik 20.000 satır kodun üretkenlik gereksinimlerimizi karşılamadığı için resmi bir tazminat aldık (sonuçta, araçlar -40.000 satır kod ürettiğimizi göstermişti). promosyonlar, eğitim, maaş artışı vb. için düşük performans göstermemize ve atlanmamıza neden oluruz. vb. proje yöneticisi ve KG ekibi müdahale etmedi ve kınadı geri aldı ve yerine bir övgüler aldı.

Birkaç ay sonra (böyle şeyler zaman alır) şirkete verimlilik standartlarını gözden geçirdiği ve fonksiyon noktası analizine dayalı yeni bir sistem oluşturmak için bir uzmanlar ekibi tuttuğunu söylemiştik.

Hiç kimsenin bahsetmediği / Birim testlerinin Kapsamını (birim testlerin uyguladığı kodun yüzdesi) bahsettiğine şaşırdım.

Kod kapsamı, uygulamanın yüzde kaçının felaketle sonuçlanmadığını bilmeniz açısından faydalıdır; geri kalan kullanışlılığı ile ünite testlerinin kalitesine bağlıdır.

Ne kadar küçük olursa, genellikle o kadar iyi olur. Bu, SCM araçlarıyla ilgilidir, kod başına değil, ama çok ölçülebilir bir ölçüdür. Taahhüt ne kadar küçükse, her değişikliği bir atomik birim olarak görmek o kadar kolay olur; ne kadar kolay olursa, belirli değişiklikleri geri almak ve işler kırılınca kesin noktaya getirmek.

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

Bunlar, ilerleme açısından çok faydalı kesin ölçütler değildir , 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 olduğunu görselleştirme açısından faydalı buldum. Genel olarak düşük bir karmaşıklık istiyorsunuz, çünkü bu modül başına kaynak sayısının düşük olduğu ve birçok modül olduğu anlamına geliyor.

Sık sık dev bir C ++ paketi üzerinde çalışıyorum ve Cyclomatic Complexity veya korkunç FanIn / FanOut'u yeniden canlandırmaya değecek sorunlu bir kod ararken genellikle aranacak iyi kırmızı bayraklar var. Buradaki problemleri çözmek genellikle kod tabanının tamamında iyileşmelere yol açacaktır.

Tabii ki bu rakamlar sadece neye bakmaya değer olduğuna dair bir ipucu olarak işlev görebilir. Bunu bir zorlu eşik yapmak, bundan sonra bir inşaatın başarısız olması veya bir taahhüdün reddedilmesi saçma olacaktır.

İşimde kod ölçümlerini kullandığım birçok durum var:

Kod yazarken

Günlük işimdeki en büyük ve belki de en önemli kullanım, Java geliştiricilerinin kodumun metriklerini (diğer şeylerin yanı sıra) sürekli tanımladığımız bir dizi kuralla karşılaştırıp kontrol eden ve kodumun uygulanmadığı yerleri işaretleyen bir aracı olan Checkstyle’de. bu kurallara uyun. Kod geliştirirken, bana geri çekilme ve daha iyi bir şeye yeniden yansıtma hakkında düşünmeme izin veren metotlarımın uzun sürdüğü, karmaşık veya eşleşmiş hale geldiğini bana gerçek zamanlı olarak söylüyor.

Geliştiriciler hiçbir zaman tüm durumlar için geçerli olmayacaklarından, tüm kuralları çiğnemekte tamamen özgürdür. "Kurallar" düşünceyi teşvik etmek ve "Hey, bunu yapmanın en iyi yolu bu mu?" Demek için varlar.

KG / Kod İncelemeleri Sırasında

Genellikle bir kod incelemesi yaparken yaptığım ilk şey, incelemekte olduğum kodun kod kapsamını kontrol etmek ve hangi kod satırının ele alındığını vurgulayan bir kod kapsamı aracıyla birlikte incelemektir. Bu bana test kodunun ne kadar kapsamlı olduğu hakkında genel bir fikir verir. Önemli kod iyi sınandığı sürece kapsamın% 20 veya% 100 olması umrumda değil. Bu nedenle, kapsanan yüzde bir miktar anlamsızdır, ancak% 0 kesin bir şekilde dikkatlice bakmak istediğim bir ağrı gibi göze çarpıyor.

Ayrıca, geliştiricinin tamam olduğunu kabul edip etmediğimi veya iyileştirmenin yollarını önerip öneremeyeceğimi görmek için, ekip tarafından kabul edilen hangi metriklerin 'kırıldığını' kontrol ediyorum. Bu geliştirme ölçütlerinin ekibimizde yeni kod yazmak için üzerinde anlaşmaya varılması, kodumuzu iyileştirmek için büyük adımlar attı. Çok daha az monolitik yöntem yazıyoruz ve şimdi tek sorumluluk ilkesinde çok daha iyiyiz .

Eski kodda trend geliştirmeler Etrafında geliştirmek istediğimiz birçok eski kod var. Herhangi bir zamandaki metrikler oldukça işe yaramaz, ancak bizim için önemli olan zamanla kod kapsamının artması ve karmaşıklık ve eşleşme gibi şeylerin azalmasıdır. Bu nedenle, ölçümlerimiz doğru yolda olduğumuzdan emin olmak için zaman içinde incelememizi sağlayan Sürekli Entegrasyon sunucumuza bağlanır.

Yeni bir kod temeliyle başa çıkma Kaynak kod metrik satırlarını ilk kez kullandığım hakkında, aşina olmadığım bir kod tabanına bakarken. Bu, birlikte çalıştığım diğerlerine kıyasla projenin kaba boyutunu hızla ölçmemi sağlıyor. Diğer ölçümleri kullanarak da projenin kalitesi hakkında daha kaba bir fikir edinebilirim.

Önemli olan şey metrikleri eğilim, tartışmalar veya ilerlemenin başlangıç ​​noktaları olarak kullanmak ve bunları kesin rakamlarla dini olarak yönetmemek. Ancak, doğru kullanıldığında doğru kodunuzu geliştirmenize yardımcı olabileceklerine inanıyorum.

S: Kaynak kod için yakalamak için yararlı ölçümler nelerdir?

İş için:

A: adam-saat sayısı

Kodlayıcı şefi için:

A: önemli değil. Bugün her şeyi yapalım

Kodlayıcının özgüveni için:

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

Coder'ın annesi için:

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

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

Unutmayın: Tüm kodlar en az 1 talimatla azaltılabilir. Tüm kodların en az 1 hatası var. Bu nedenle, tüm kodlar çalışmayan tek bir komutla azaltılabilir. Umarım yardımcı olur!