Ampirik metriklere dayalı olarak yazılımın iyi mi kötü mü olduğunu nasıl anlarsınız?


18

Şu anda benden beş ay önce çekirdek gelişimini bitirmiş, ancak hala yüksek düzeyde kusurları olan bir projeye bakmam isteniyor. Transpires yaklaşık 10 kusur için sabittir, en az 4 ve bazı durumlarda 8 kusur yükseltiriz.

Satıcıdaki kodlama uygulamasının kötü olduğuna ve bununla ilgili genel bir anlaşma olduğuna inanıyorum. Ancak, yazılımda yapısal bir sorun olup olmadığını merak ediyorum? Hata yoğunluğu yararlı bir önlemdir, ancak çekirdek yazılım kötü yazılmışsa, daha sonra satıcının yaptığı tüm problemi değiştirmektedir.

Altyapıda, bir şeyin kötü inşa edilmesi durumunda daha tanımlanır, LOC başına kusurların yanı sıra yazılım için hangi ölçümleri kullanabilirsiniz?

Ürün 4 aydır hata düzeltme aşamasındadır ve hala yeterince kritik kusuru çözmemiştir. Yeni işlevsellik enjekte etmiyoruz, sadece regresyon sorunlarını düzeltiyoruz.

Bu, memnun olmayan bir geliştirme kalitesi sorununu gösterir. Ancak, ürünün kendisi temelde kusurluysa, bu farklı bir sorundur. Temel kod tabanının kötü yazılmış ve sınırlı belgelendirmeye sahip olmasıyla ilgili olarak, tüm harici geliştiricilerin sorunu A'dan B'ye kaydırmasıdır. Dahili geliştirme ekipleri devraldıktan sonra, işlevsel olsun.

Dolayısıyla, bir ürünü üçüncü bir taraftan kabul ettiğinizde ve desteklemesi istendiğinde, standartları tanımlamak için hangi kabul kriterlerini kullanırsınız?

Baş geliştiricimize, sürüm başına kodun hakem değerlendirmesini yapmanın yanı sıra, başka neler yapılabileceğinden emin değil misiniz?


8
İyi bir yazılım için yararlı bir ampirik (otomatik olarak hesaplanabilir) metrik olsaydı, insanlar bunu gereksinim belgelerinde kullanırdı. Derleyici yazarları bunun için optimize ederler. Yazılımın ne kadar iyi olduğu konusunda hiçbir zaman anlaşmazlık olamazdı. Açıkçası, dünya böyle değil. Bu, böyle bir önlemin mevcut olmadığı veya en azından hiçbirinin bilinmediği için güçlü bir ipucu.
Kilian Foth


Kusurlar birçok nedenden ötürü ortaya çıkar - spesifikasyona sahip hatalar, testteki hatalar, belirsiz / değişen gereksinimler. Hepsi geliştirici hatalarına atfedilemez.
Robbie Dee


1
Soru, kusurlara çok fazla odaklanarak, yetersiz bir ifadeyle ifade edilebilir. Başlıktaki sorunun geçerli olduğunu ve yinelenen bir şey olmadığını düşünüyorum (bağlantılı kalitedeki sw kalitesine karşılık sw verimliliğini değerlendirmek)
Frank

Yanıtlar:


23

Yapmazsın.

Yazılım kalitesini objektif olarak ölçmek gerçekten zor. Bir çözüm olmayacak kadar zor. Bu cevapta, bir çözüm olup olmadığını sormak için reddediyorum, ama basitçe bir taneyi tanımlamanın neden zor olacağını belirtin.

Statükoya göre akıl yürütme

Kilian Foth'un belirttiği gibi, "iyi" yazılım için basit bir önlem olsaydı, hepimiz onu kullanardık ve herkes bunu isterdi.

Yöneticilerin belirli ölçümleri uygulamaya karar verdikleri projeler var. Bazen işe yaradı, bazen işe yaramadı. Önemli korelasyonların farkında değilim. Özellikle kritik sistem yazılımları (uçaklar, arabalar vb. Düşünüyorum) SW kalitesini "sağlamak" için çok fazla metrik gereksinimine sahiptir. aykırı.

Karşı istihbarat ile akıl yürütme

Ayrıca Kilian tarafından zaten ima edildi ve daha genel olarak "her metrik oynanabilir ve oynanacak" olarak ifade edildi.

Bir metrik oynamak ne anlama geliyor? Geliştiriciler için eğlenceli bir oyun: metrik değerlerin gerçekten iyi görünmesini sağlarken, gerçekten boktan şeyler yaparsınız.

Diyelim ki LOC başına hataları ölçtünüz. Bunu nasıl oynayacağım? Kolay - sadece daha fazla kod ekleyin! 100 satırda işlem yapılmamasına neden olan aptal kod oluşturun ve aniden LOC başına daha az kusurunuz var. En iyisi: aslında yazılım kalitesini bu şekilde düşürdünüz.

Araç eksiklikleri istismar edilir, tanımlar maks., Tamamen yeni yollar icat edilir.

Bu, metriklerin her zaman kötü olduğu anlamına gelmez - ancak ekibin bu metriklere karşı tutumu çok önemlidir. Özellikle, bu, herhangi bir taşeron / 3. taraf satıcı ilişkisi için iyi çalışmayacağı anlamına gelir.

Yanlış hedefleme ile akıl yürütme

Ölçmek istediğiniz şey yazılım kalitesidir. Ölçtüğünüz şey bir veya daha fazla metriktir.

Ölçtüğünüz ve size söyleyeceğine inandığınız şeyler arasında bir boşluk var. Bu boşluk biraz büyük.

Her zaman etrafımızdaki her türlü işte olur. KPI'lara dayanan kararlar gördünüz mü (temel performans göstergeleri)? Bu sadece aynı sorun - bir şirketin başarılı olmasını istiyorsunuz, ama başka bir şey ölçüyorsunuz.

Ölçülebilirlik ile akıl yürütme

Metrikler ölçülebilir. Onlarla hiç ilgilenmemizin tek nedeni bu. Bununla birlikte, yazılım kalitesi bu ölçülebilir varlıkların ötesine uzanır ve bunun ölçülmesi çok zordur: Kaynak kodu ne kadar okunabilir? Tasarımınız ne kadar genişletilebilir? Yeni ekip üyelerinin katılımı ne kadar zor? vs vs.

Yazılım kalitesini yalnızca metriklerle değerlendirmek ve kaliteyi ölçemediğiniz kısımlara körleştirmek kesinlikle iyi sonuç vermeyecektir.

Düzenle:

özet

Yukarıdakilerin tamamen metriklere dayalı olarak yazılımın iyi mi kötü mü olduğunu objektif olarak değerlendirmeyle ilgili olduğunu belirteyim. Bu, metrikleri uygulamak isteyip istemediğiniz ve ne zaman uygulamanız gerektiği hakkında bir şey söylemiyor demektir.

Aslında, bu tek yönlü bir sonuçtur: kötü metrikler kötü kod anlamına gelir. Tek yönlü, kötü kodun kötü metrikleri ve iyi metriklerin iyi kodu garanti etmediği anlamına gelir. Öte yandan, bu kendi başına bir yazılım parçasını yargılamak için metrikler uygulayabileceğiniz anlamına gelir - bu sonucu aklınızda tutarken.

A yazılımını ölçüyorsunuz ve metrikler gerçekten kötü oluyor. O zaman kod kalitesinin kötü olduğundan emin olabilirsiniz. B yazılımını ölçtünüz ve metrikler iyi, kod kalitesi hakkında hiçbir fikriniz yok. Gerçekten "metrikler iyi => metrikler iyi" olduğunda "metrikler iyi = kod iyi" diye düşünmeye aldanmayın.

Özünde, kalite sorunlarını bulmak için metrikleri kullanabilirsiniz, ancak kalitenin kendisini değil.


Tut. Etkin bir şekilde yazılımın bir metin parçasına benzediğini söylüyorsunuz, IE bir edebiyat biçimidir. Farklı olmak için fiziksel ürünler ile kod arasındaki karşılaştırmayı anlayın. Ancak, beşeri bilimler uzun süredir doktora yapıyorlar ve kaliteyi ölçmek zorundalar. Buradaki sorunun teknik olarak kod işaretlemesi zor olduğunu düşünüyorum. Ancak, bir uygulama mağazasında aynı fiyata iki uygulama gibi diğer metrikleri uygulayın, ancak daha fazla işlevsellik ve daha iyi bir derecelendirme var, satın aldığınız.
Göçebe teknoloji

Ölçme konusundaki diğer noktalarınıza göre, karşılaştırmadır. Üç farklı ürünü destekliyorsanız, destek işlevinizin doğal olarak kaynak kodunu kolayca okuyabileceği ve yeni üyelerin benimseyeceği gibi olmasını istersiniz. Hakkında en az bilet / değişiklik talebi aldığınız ürün olacaktır. Belki de kısaca cevap, yazılım kodunu kendi hatlarıyla değerlendiremezsiniz. Ancak son kullanıcılar ve onu destekleyenler ve üretim sistemlerinde minimum bozulma ile devam edip edemeyeceği.
Göçebe teknoloji

1
Genel yazılım kalitesinin bir metrikle ölçülmesinin zor olduğunu kabul ediyorum, ancak daha az kaliteye işaret edebilecek veya eğilebilecek birkaç metrik var.
Jon Raynor

Tamam, bir metrik oyun oynamak sorun olabilir. Ama bence daha da kötüsü doğru şeyi yaptığım için cezalandırılmam. Sadece 100 satır bozuk kod tek satırlık bir kütüphane çağrısı ile değiştirerek bir kusur düzeltildi ve bana metriğinize göre kodu daha da kötüleştirdiğimi mi söylüyorsunuz? Bu beni iyi bir iş yapmaya motive etmeyecek.
svick

Eğer "cezalandırılıyorsanız" zaten metrikleri doğru kullanmıyorsunuzdur. Metrikleri programcı üretkenliğine bağlamak, tipik de olsa başarısız olmanın kesin bir yoludur.
Frank

13

Evet, metriklere bir dereceye kadar bakarak kodun kalite sorunları olduğunu söyleyebilirsiniz.

Daha spesifik olarak, kod tabanında bir karmaşıklık analiz aracı çalıştırın ve kodun iyi mi yoksa kötü mü olduğu hakkında bir fikir edineceksiniz.

Örneğin, kaynak izleyicisini çalıştırabilirsiniz .

Bunun size söyleyeceği kodun ne kadar karmaşık olduğudur. Size yaşadığım her problemli sistemin kötü sayıları olduğunu söyleyebilirim. 10'lardan 100'lere kadar olan yöntemlerde kabul edilebilir sınırların çok üzerinde karmaşıklık. Korkunç sayılar. Korkunç karmaşıklık, yuvalama, derinlik, vb. Bu, birçok soruna, sürekli yüksek hata oranına, değişiklik yapmak zor, başka bir şey kırmadan vb.

Başka bir şey kusurlar. Zamanla sistem stabilize olmalıdır. İdeal olarak yeni kusurlar sıfıra doğru eğilim göstermeli veya düşük bir sayıya yaslanmalı, yani yeni ve mevcut kusurlar zamanla azalmalıdır.

Arsa şöyle görünmelidir:

Zaman İçinde Kusurlar Zaman İçinde Kusurlar

Sabit kalırlarsa veya artarlarsa, yazılım iyi değildir. Sadece 4 ay içinde, bu yüzden birkaç aydan bir yıla kadar veririm. 6 aydan bir yıla kadar, sürekli bir kusur akışınız varsa, o zaman kötü kalite. Takımınız başka bir çamur topu geliştirdi .

Sonraki testler. Onları var mı? Daha az kalite yoksa, daha fazla hata, daha fazla karmaşa. Bunlara sahipseniz, kod kapsamı gibi metrikler, ne kadar kodun ele alındığına dair bir fikir edinmek için iyidir, ancak kaliteyi ölçmez . Ben büyük kod kapsama numaraları gördüm ama gerçek testler bok oldu. Sistemin herhangi bir davranışını veya işlevselliğini test etmiyorlardı. Geliştiriciler sadece yönetim için metrik sayılarını artırmak için yazıyorlardı. Bu yüzden testler yaptırmalısınız ve iyi olmalılar. Kod kapsamı metrikleri kendi başlarına kalitenin göstergesi değildir.

Kod incelemeleri, bunları gerçekleştiriyor musunuz? Değilse, daha az kalite. Bu özellikle küçük geliştiriciler için önemlidir. Çevik yapıyorsanız, hikayenize "kod incelemesi" adı verilen bir kod inceleme görevi ekleyin. Yönetim sayıları izlemek istiyorsa, Crucible gibi incelemeleri izleyen bir araca ihtiyacınız olacaktır . Kod inceleme sayılarının veya metriklerinin, işleminizin bir parçası olmaları dışında burada o kadar önemli olmadığını düşünüyorum. Her check-in'in gözden geçirilmesi gerekmez. Ancak, incelemeler insanların tekerleği yeniden icat etmediğinden veya başkalarının anlayamadığı ve / veya koruyamadığı bir kod yazmadığından emin olabilir.

Son olarak, kodu değerlendirmeniz gerekecek, hiçbir metrik bundan daha fazla yardımcı olmayacaktır. Her sorunlu kod projesi şu özelliklere sahiptir:

  • Kötü veri yapıları. Her şey bir dizedir veya XML her yere aktarılır ve her yerde, tanrı nesneleri veya gereksiz yere karmaşık veya genel veri yapıları, etki alanı modeli olmadan ayrıştırılır.
  • Organizasyon veya yapı eksikliği, önemsiz olmayan herhangi bir projenin mantığı ayıran bir bölüm veya katman içermesi gerekir. Buraya bir göz atın ... Bu tip bir organizasyon veya ayrılma (her yerde mantığın karıştırılması) görmüyorsanız, sistemin bakımı ve anlaşılması daha zor olacaktır.
  • Aşırı soyutlamalar. Bazen bunun tersi doğrudur, sistem aşırı soyutlanmıştır. Her şey bir arabirim ve soyut bir sınıfsa veya bir ton sınıf "sarmalayıcı" türü sınıfta gezinmeniz gerekiyorsa, kalite kötü olacaktır, çünkü yeni geliştiriciler nesne şişkinliğinde gezinemeyecektir.
  • Kodu anlamak zor. Deneyimli bir geliştiriciniz ve anlaşılması zor bir kod arıyorsanız, kalite sorunları olacaktır. Kişisel ölçüt, koda bakıyorsam ve zor takip edersem ya da aptal hissetmemi sağlıyorsa ya da mantığı anlamak için çok fazla beyin döngüsü harcadığımı hissediyorum, o zaman kötü kod. Tecrübeli geliştiriciler takip etmekte zorlanıyorlarsa, yeni geliştiriciler için nasıl bir şey olacağını hayal edin. Sorunlar getirecekler.

Benim tavsiyem kod üzerinde bir karmaşıklık analizi yapmak olacaktır. Sonuçları paylaşmayın, bunun yerine sonuçları takip edin, bazı bağımsız araştırmalar yapın (koda bakın) ve kod tabanının genel sağlığını belirleyin. Bundan sonra, bir eylem planı oluşturun ve kodun bazı karmaşık alanlarını düzeltmeyi deneyin.


3
Sen yazdım: "Kişisel ölçüt, koda bakıyorsam ve zor takip edersem ya da aptal hissetmemi sağlıyorsa ya da mantığı anlamak için çok fazla beyin döngüsü harcadığımı hissediyorum, o zaman kötü kod". Yaşlandıkça buna katılıyorum. Daha önce bunun görkemli bir bakış açısı olduğunu düşündüm. Ancak, şimdi zarif kod içine yeniden pek çok karmaşık görünüyor süreçler gördük göre zor kod neredeyse her zaman daha net yazılmış olabilir farkında.
Ivan

Teşekkürler Jon. Verdiğiniz referanslar faydalıdır. Açık olmak gerekirse, yazılım bir yıldan daha eski ve kusurlar ortadan kalkmadı. Şahsen yıllar içinde kodlama yapmadım, çok uzun süredir yönetici değilim, teknik değil. Okuma BT ve kitap düşüncelerimi yankılıyor. IE, üzerinde çalışan donanım yazılımının ne kadar iyi yazıldığını anlatacak bir işaret olacaktır. Tekrar çok teşekkürler.
Göçebe teknoloji

Kodun iyi mi kötü mü olduğuna dair cesaretli duygular kötü kodu saptamaya yardımcı olabilirken, bunlar neredeyse metrik değildir. Ve biçimlendirme ve yöntem / değişken adlandırma temelinde "kötü kod" tespit etmek için otomatik süreçler, bir takım içinde tutarlı adlandırma kuralları uygulamak dışında hiçbir şey yapmaz (iyi olsa da gerçek kod kalitesini garanti etmez veya ölçmez).
jwenting

2
Siklomatik karmaşıklığa, kalıtımın derinliğine, sınıf bağlantı derecesine ek olarak ve eminim birkaç diğerleri, alt-par kodunun büyük göstergeleri olabilir. Yalnızca kalitenin bir göstergesi olarak kullanılamazlar , ancak oldukça iyi bir başlangıç ​​noktası verebilirler.
RubberDuck

3

Metriklerle ilgili üzücü olan şey, metriklerinizin sonuç değerlerini iyileştirebileceğiniz, ancak onlar tarafından ölçülmesi amaçlanan kalitenin değil ...

Visual Studio'da, derleyici uyarılarını hata olarak değerlendirmek için bir ayar vardır. Şimdi bazı insanlar uyarıları anlamıyor ve kodun derlenmesini sağlamak için basit hileler (´pragma devre dışı bırakma uyarısı´ gibi) veya bir üssün sanal olmayan bir üyesini gizleyen bir işleve / özelliğe ´new´ anahtar sözcüğü ekleyecek sınıf).

Kaynak koda erişiminiz varsa, statik kod analizini çalıştırabilirsiniz. Net projeleri için örneğin FxCop veya ReSharper InspectCode kullanabilirsiniz. Gelişen ekip tarafından doğru kullanıldığında, araçlar kaliteyi artırmaya yardımcı olacaktır. Ancak elbette, uyarıları anlamadan kaldırmak için bazı "düzeltmeler" mümkündür.

Otomatik testlere / UnitTest'lere bakabilirsiniz: kod kapsamı ne kadar iyi? Ancak kapsam yalnızca testlerin kodu gerçekten kontrol edip etmediğini veya sadece bir kez çalıştırıldığını size söylemez.

Yüksek kalite için çabalamak, birçok araç ve metrikleri tarafından desteklenebilen bir tutumdur, ancak geliştiricilerin tutumu olmadan metrikler yardımcı olmaz.


3

Bir metrik benzeri kusur enjeksiyonunu toplamanın yanı sıra bakmanız gereken bir şey de kusurların kaynağını bulmaktır. Çoğu zaman şartname ile ilgilidir.

Temel olarak, spesifikasyondaki bir hatadır, implantların karar vermesi için bırakılan bir belirsizlik midir yoksa uygulamada bir hatadır.

Daha kalitatif bir yaklaşım, yazılımın yararlı olup olmadığını sormaktır. Yeterince sert bakarsanız, herhangi bir yazılımda kusur bulabilirsiniz. Ancak, para kazanmak için yeterince iyi çalışıyorsa, o kadar da kötü olmayabilir.


1
+1 Harika yanıt - hataların kaynağını ele almamak aynı kaynaktan daha fazla hata için kapıyı açık bırakıyor
Robbie Dee

3

Altta, bilmenin bir yolu yok.

Orijinal soru için (felsefi cevaptan önce): Ürün ne yapmalı ve yapıyor mu? Hata sayısı / yoğunluğu ile ölçüm yeterli değildir. Bunun bir kütüphane ya da bir uygulama olup olmadığını, kod tabanının ne kadar büyük olduğunu, sorunlu alanın ne kadar büyük olduğunu ya da kusurların şiddetinin ne olduğunu söyleyemedim. Örneğin, 123 giriş biçimlerinden birini kullanmamak, düzgün biçimde işlenmeyen biçimin önemine bağlı olarak önemsiz bir hata veya şov durdurucusu olabilir. Ve hiç yoktan iyidir, yüksek bir standarttır.

Bu soru için yaptığım varsayım: Kod ile Yazılım arasında bir fark vardır. Yazılımı bir istemcinin / kullanıcının bir sorunu çözmek için kullandığı yöntem olarak tanımlarken, kod yazılımın yapı malzemesidir.

Yazılım yalnızca öznel olarak ölçülebilir. Yani, yazılım için önemli olan metrik, insanların bir sorunu çözmek için kullanıp kullanmadığıdır. Bu metrik, başkalarının davranışına, dolayısıyla öznel olarak bağlıdır. Not: Bazı sorunlar için bir yazılım parçası oldukça yararlı olabilir ve bu nedenle yüksek kalite (hesaplamalar için Excel) olarak kabul edilebilir, ancak farklı bir sorun için kaliteli yazılım (MP3 dosyalarını çalmak için Excel) olarak düşünülemez.

Kod (genellikle) ampirik metriklerle ölçülebilir . Fakat yorumlama kalite için 'evet / hayır', hatta gerçekten '0'dan N'ye kadar olan bir ölçekte değildir. Metrikler bir standarda göre ölçülür. Dolayısıyla, metrikler standart tarafından tanımlanan endişe alanlarını bulabilir, ancak endişe alanlarının olmaması bunun kalite kodu olduğunun kanıtı değildir. Örneğin, yararlı metrikler: Derleniyor mu? Hayır -> Kalite değil. Evet -> ???. Birim Testini geçiyor mu? Hayır? Olabilir? (ünite Test Kalite Kodu Var mı?), Evet -> ???.

Yani, Godel'in Eksiklik Kanıtı'nın matematiksel aksiyomları için gösterdiği gibi (yani, herhangi bir sonlu aksiyom seti için doğru veya yanlış kanıtlanamayan matematiksel ifadeler var), sanırım hiç cevaplayamayacağımızı sanmıyorum '' şifresi?' her kod parçası için. Sezgisel olarak, muhtemelen orada kaliteyi cevaplamak için yazılım metrikleri ile muhtemelen doğru veya yanlış cevaplamak için matematiksel aksiyomlar arasında bir eşleme vardır.

Bu tartışmayı yapmanın bir başka yolu da doğal dile adım atmaktır. William Shakespeare, Lewis Carroll ve Mark Twain başarılı yazarlardı ve birçoğunun yazılarının kalitesi için sevgililerdi. Yine de, onları rastgele 12. sınıflardan daha yüksek olarak derecelendirecek hangi dilbilgisi, kelime bilgisi, stil veya ses standardını uygulayabiliriz? Ve bu üçü için sentetik bir ölçü oluşturmak mümkün olsa da, John Kitabı (KJV), JRR Tolkien, Homer, Cervantes, vb. Sonra Burroughs, Faulkner, Hemingway, Sylvia Plath, vb. Metrik çalışmaz.


2

Bunu, süreçlerini denetleyerek (ve sapmaları arayarak) ölçeceğim.

Merkezi kaynak kontrolü, merkezi yapı sistemi ve serbest bırakılan şubeye entegrasyondan önce kodun test edilmesini sağlayan bir süreci sağlamak için bir sürecin kanıtını ararım.

Ayrıca, kusurların serbest bırakma sürecinden geçtiği durumlara yanıt olarak süreçlerini nasıl değiştirdiklerine dair kanıtlar da ararım.

Bu denetim seviyesini geçemezlerse, tutarlı güvenilir sürümler vermelerini bekleyemezsiniz.

Bu denetimi geçirdikleri ve süreçlerini sürekli iyileştirdikleri takdirde, çıktılarının tutarlılığı zaman içinde artacaktır.

Bu sorunu çözmezse, muhtemelen mevcut kod tabanını genişletmeyi ve test etmeyi zorlaştıran bir kod mimari problemi vardır, bu durumda iyi bir seçenek yoktur.


Aradığım cevap budur.
Göçebe teknoloji

0

Tamamen otomatik ölçümler arıyorsanız, şu adamları öneriyorum: Yazılım Geliştirme Grubu

Temelde, kaynak koddan otomatik olarak çıkarılabilen çeşitli metriklerin bir toplamıdır (birim test kapsamı, işlev boyutu, sınıf dolaşımı, çoğaltma, LOC vb.). Bu değerler daha sonra 1-5 yıldız derecesine dönüştürülür.

resim açıklamasını buraya girin

Ayrıca pratikte tüm metriklerini açıklamaya değer iyi bir kitabı var: 'Bina Sürdürülebilir Yazılım' .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.