Bir kod tabanının teknik borcunu bir tür kod ölçüsü olarak koymak için bir tür araç olup olmadığını bilen var mı? Olmazsa, bunun için bir algoritma veya sezgisel taramadan haberi olan var mı?

Bu şeylerin hiçbiri şu ana kadar mevcut değilse, böyle bir şeye nasıl başlayacağınızla ilgili fikirlerle ilgilenirim. Yani, bir yöntem, sınıf, ad alanı, montaj vb. İle oluşan teknik borçları nasıl ölçebilirim?

En çok bir C # kod tabanını analiz etmek ve değerlendirmekle ilgileniyorum, ancak özellikle de diller aşkınsa, lütfen diğer diller için de çekinmeyin.

Teknik borç, bir sistemi tasarlama, inşa etme, test etme ve sürdürme hatları boyunca bir yerde, ürünün test edilmesi ve bakımı daha zor hale gelene kadar kesin kararların alındığı soyut bir fikirdir. Daha fazla teknik borç sahibi olmak, bir sistem geliştirmeye devam etmenin daha zor olacağı anlamına gelir - ya teknik borçla başa çıkmanız ve aksi halde basit görevlerin ne olacağı için daha fazla zaman ayırmanız ya da kaynaklara yatırım yapmanız (zaman ve para) kodu yeniden düzenleyerek, testleri iyileştirerek vb.

Kodun kalitesi hakkında size bazı bilgiler verebilecek birkaç ölçüm vardır:

• Kod kapsamı. Orada çeşitli araçlardır birim testleri ile kaplıdır senin fonksiyonları, tablolar ve hatların yüzde kaçının söyleyecektir. Ayrıca, sistem düzeyinde bir test kapsamında olan gereksinimlerin yüzdesini belirlemek için sistemi ve kabul testlerini gereksinimlere geri döndürebilirsiniz. Uygun kapsam, başvurunun niteliğine bağlıdır.
• Birleştirme ve uyum . Düşük bağlantı ve yüksek uyum gösteren kodun okunması, anlaşılması ve test edilmesi genellikle kolaydır. Belirli bir sistemde bağlanma ve uyum miktarını raporlayabilen kod analiz araçları vardır.
• Siklomatik karmaşıklık , bir uygulamadaki benzersiz yolların sayısıdır. Genellikle yöntem / işlev düzeyinde sayılır. Siklomatik karmaşıklık, bir modülün anlaşılabilirliği ve test edilebilirliği ile ilgilidir. Sadece daha yüksek döngüsel karmaşıklık değerleri, birisinin kodu takip etmekte daha fazla sorun yaşayacağını göstermekle kalmaz, aynı zamanda döngüsel karmaşıklık, kapsama almak için gereken test vakalarının sayısını da gösterir.
• Çeşitli Halstead karmaşıklığı önlemleri , kodun okunabilirliği hakkında fikir verir. Bunlar, hacim, zorluk ve eforu belirlemek için operatörleri ve operatörleri sayar. Genellikle, bunlar, birisinin kodu alması ve anlaması, genellikle bir kod incelemesi veya kod tabanındaki yeni bir geliştirici gibi durumlarda, ne kadar zor olacağını gösterebilir.
• Çift kodun miktarı. Çoğaltılmış kod, yöntemlere yeniden düzenleme potansiyelini gösterebilir. Çift kod olması, bir hatanın ortaya çıkması için daha fazla satır olduğu ve aynı kusurların birden fazla yerde var olma olasılığının daha yüksek olduğu anlamına gelir. Aynı işletme mantığı birden fazla yerde mevcutsa, değişiklikleri hesaba katacak sistemi güncellemek zorlaşır.

Genellikle, statik analiz araçları sizi olası problemler konusunda uyaracaktır. Elbette, bir araç bir sorunun bir sorun olduğu anlamına gelmediği için bir sorun olduğu anlamına gelmez - yolda bir şeyin sorunlu olup olmayacağını belirlemek insan kararını alır. Bu ölçütler, bir sisteme veya modüle daha yakından bakmanın zamanı olabileceği konusunda size uyarıda bulunur.

Ancak, bu özellikler koda odaklanır. Sistem mimarinizde veya tasarımınızda, çeşitli kalite nitelikleri ile ilgili olabilecek herhangi bir teknik borcu kolayca belirtmezler.

Sonar'ın teknik borçlu bir sezgisel yanı sıra bir yazılım projesine faydalı diğer bazı özellikleri vardır.

Aynı zamanda oldukça geniş bir dil yelpazesini destekler.

SonarQube (eski Sonar ), kod kalitesinin Sürekli Denetimi için açık kaynaklı bir platformdur ...

• 25+ dili destekleyin: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL, vb.
• SonarQube ayrıca Android Geliştirme'de kullanılır.
• Yinelenen kod, kodlama standartları, birim testleri, kod kapsamı, karmaşık kod, olası hatalar, yorumlar ve tasarım ve mimari hakkında raporlar sunar.
• Zaman makinesi ve farklı görünümler.
• Tam otomatik analizler: Maven, Ant, Gradle ve sürekli entegrasyon araçlarıyla (Atlassian Bamboo, Jenkins, Hudson, vb.) Bütünleşir.
• Eclipse geliştirme ortamı ile bütünleşir
• Harici araçlarla bütünleşir: JIRA, Mantis, LDAP, Fortify, vb.
• Eklentilerin kullanımı ile genişletilebilir.
• Teknik borcu hesaplamak için SQALE metodolojisini uygular ...

Finanstan bir analoji kullanmaktan nefret ediyorum ama gerçekten uygun görünüyor. Bir şeyi fiyatlandırırken (her türlü varlık), hem iç hem de dışsal değere sahip olabilir. Bu durumda, mevcut kod, bahsedilen kodun nispi kalitesine tekabül eden bir miktar olacak ve ayrıca dış değere (kodda yapılabilecek değerden) sahip olacak ve bu miktarlar ilave olacaktır. İçsel değer, kodu puanlamak için kullandığınız metodolojiyi kullanarak (yorumlar / okunabilirlik için +5, kod kapsamı için -10 vb.) Kullanılarak kredi ve borçlara (iyi veya kötü) ayrılabilir.

Bugün bunu ölçen herhangi bir araçtan kesinlikle haberim yok ve farklı "borç değerleme" stratejilerinin değerlerini tartışırsanız ellerinizde tamamen yeni bir tartışma olacağını düşünüyorum, ancak Matthew - Kodu almak için kullanabileceğiniz kadar iyi bir maliyet, muhtemelen oraya gitmek için harcadığınız çalışma saatlerini hesaplamak için kullandığınız yöntemi kullanın.

Dikkate alınacak başka bir şey, kesinlikle “maliyet” e yaklaştığında, kod tabanında harcanan bir saatin değerinin üssel olarak düşmesinden daha fazla olduğu ve maliyet bazında harcanan bir saatin değerinin katlanarak daha fazla olması gerektiğidir. Yapılan işin faydasını maksimize etmek.

Geliştiriciler arasında oldukça güvenilir bir teknik borcun ölçüsü WTF / dakika gibi görünüyor .

_{Bu "metrik" ile ilgili sorun, "dış" iletişim kurmanın genellikle oldukça zor olmasıdır.}

Teknik borçları "yabancılara" iletmede benim için çalışan Metrik, başarılı bir teslimat için gerekli olan test ve hata düzeltme çabalarının (özellikle de regresyon hatalarını düzeltmek için ) gerekli olmasıydı .

Dikkatli bir kelime: Bu yaklaşım oldukça güçlü olsa da, iyi eski WTF'leri / dakikaya başvurmadan önce bir kez daha iki kez kontrol etmeliyiz . Şey, oldukça zordur: veriyi elde etmek için, birinin dikkatle izini sürmesi ve uygun kategorilere göre doğru şekilde kaydetmesi gerekir.

• çok daha kolay duruma ise 3 hafta toplam harcanan özelliği A uygulanmasına ilişkin daha
   
  ben QA test Sonra 18 saat, keşfedilen regresyonlar için düzeltmeler uygulama üzerinde daha sonra 29 saat duman testinde özellik A'nın taslak uygulanmasına ilişkin daha sonra 11 saat 14 saat geçirdim - zaten özellik uygulaması. Bundan sonra, KG üyeleri ilk aday adayın sınava girmesi için 17 saat harcadı. Bundan sonra, ilk adayın serbest bırakılması için KG tarafından gönderilen hataları analiz etmek ve düzeltmeleri uygulamak için 3 saatimi harcadım. Ondan sonra 11 saatimi ilk aday sürümde yaptığım değişiklikleri test etmek için harcadım. Daha sonra...

Yine de test etme ve hata giderme çabaları hakkındaki veriler tecrübelerime göre iletişim kurmak oldukça kolaydı.

Son sürümlerde, regresyon hatalarını test etmek ve düzeltmek için yaklaşık% 90 zaman harcadık. Bir sonraki sürüm için, bu değeri% 60-70'e düşürmek için biraz çaba sarfedilmesini önerin.

Dikkatli bir başka kelime. Yukarıdaki % 90 gibi veriler, yalnızca teknik borcun bir göstergesi değil, aynı zamanda (sürpriz bir sürpriz) birinin programlama / özel teknolojide yeterince uzman olmadığının bir göstergesi olarak yorumlanabilir. "Kodunuzda çok fazla hata yapıyorsunuz".

Verilerin bu şekilde yanlış yorumlanma riski varsa, karşılaştırmak için WTF'den daha az eğilimli bir şey hakkında ek bir referans verisinin bulunmasına yardımcı olur .

• Aynı geliştirici (ler) tarafından sağlanan iki benzer bileşen / uygulama varsa, önce "% 50 oranında" atık oranında "ve ikinci olarak 80 - 90'da serbest bırakılırsa, bu ikinci teknik borca ​​tabi olmak lehine oldukça güçlü bir durum yaratır .

Projede özel test cihazları varsa, verilerin daha objektif bir şekilde değerlendirilmesine de katkıda bulunabilirler. Başka bir cevapta bahsettiğim gibi ,

Test cihazları ile tasarım konularındaki anlayışınızı destekleyecek birini bulursunuz. Yalnızca kod kalitesinden şikayetçi olan geliştiriciler olduğunda , bu genellikle kapalı kapının arkasından öznel WTF'ler gibi görünür .
 
Fakat bu, QA adamı tarafından component Atekrar component Bedildiğinde , 10 yeni özellik için 100 regresyon hatası olduğunu, bunun yerine 20 yeni özellik için 10 regresyon hatası olduğunu söylediğinde , iletişim aniden bir başka oyuna dönüşüyor.

Bence asıl soru, teknik borcunuzu "geri almanın" ne kadara mal olacağını - yani, düzeltmek için ne kadar çalışacağı? Bunu çözmek takımın görevi.

Sprint planlaması sırasında, ekibin teknik borç kalemlerini sabitlemenin karmaşıklığını, bir kullanıcı hikayesinin karmaşıklığını tahmin ettiği gibi tahmin etmelerini istiyorum. Bu noktada, takım ile ürün sahibi arasında, hangi teknik borcun mevcut sprintte (gerçek kullanıcı hikayelerinin yerine koyularak) yapılacağına kadar öncelikli olduğunu ve ne bekleyebileceğini belirleyen, müzakere oyunu.

Eğer scrum yapmıyorsanız, öncülüme bağlı kalacağım - teknik borç çare maliyeti ile ölçülmelidir.

CAST adında oldukça güçlü bir platform var.büyük uygulamalarda teknik borç aramak. Eski bir sistemde büyük bir geliştirme devraldığımız bir projede kullandık. Size kodu yazan kişilerin kafasında ne olduğunu söylemez, ancak kodu inceler ve kod ve mimari kusurlarını bulur, sonra isterseniz teknik borcu belirler. Buna bakarken, asıl kullanım $ tutarı değil, koddaki problemlerin listesi. Bu size sahip olduğunuz teknik borcun bir kısmını anlatır (bu yüzden yukarıdaki cevapların bazılarına katılmıyorum). Tamamen tasarıma dayalı ve çok öznel olan bazı teknik borçlar var - pornografi gibi - onu gördüğünüzde ve bağlamı bildiğiniz zaman. Bunun gerçekten "teknik" bir borç olup olmadığını tartışırdım. Tamamen uygulamada bazı teknik borçlar var ve inanıyorum '

İşte büyük yazılım sistemlerinde teknik borç araştırmalarını açıklayan MIT'den bir Webinar: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Yazarlar bir projeyi analiz etmek ve 'mimari karmaşıklık' ölçümlerini çıkarmak için kod yazdılar. Bu ölçümlerin hata yoğunluğu, geliştirici üretkenliği ve geliştirme personeli devri ile güçlü bir ilişkisi olduğu gösterilmiştir.

Webinar'da açıklanan çalışma, Harvard Business School'da Alan MacCormack ve Carliss Baldwin tarafından yapılan modülerlik araştırmasına dayanıyor. Onların makalelerine de bakardım. Onların 'yayılma maliyeti' aradığınız şey olabilir.

Standart kod ölçümlerinin teknik borçluluğun göreceli olarak üst düzey bir görünümü olarak kullanılabileceğini söyleyebilirim . VS Ultimate, Cyclomatic Complexity, Coupling, LoC ve Miras Derinliklerine dayanarak size bir "Bakım Kolaylığı Dizini" verecek bir Kod Analizörü içerir. Herhangi bir sorunlu bölgeye dalabilir ve ayrıntıları görebilirsiniz (işlev seviyesine kadar). Sadece projemde koştum ve elde ettiğimiz en düşük puanlar Veri paketimizde (EF yapılandırma ve başlatma) 69 ve Test Süitimizdeydi. Her şey 90 ya da üstü idi. Size daha fazla metrik verecek diğer araçlar vardır tartışılan olduğu gibi Bob Amcanın içinde PPP

Teknik borcu, onu ölçmek için süslü bir modele ihtiyacınız olan dolarlar olarak düşünmem. Bunu iyilik olarak düşünürdüm. Birisi size bir iyilik yaparsa ve unutacaksanız, bir yere not edin. Kısa bir kesim yaptığınızda, bir yere yazın. Bu, hatırlamanıza yardımcı olur ve daha iktidarsızlık sizi onaylamaya zorlar. Süslü bir alete gerek yok. Not defteri veya Ecxel hile yapabilir.

Bunu tam olarak arayan bir şirket için çalışıyorum. Aşağıda, teknik borçlarla mücadele ederken göz önüne almanızı önerdiğimiz 3 işlem yapılabilir metrik bulunmaktadır. Onları izlemek için "nasıl" ve "ne zaman" hakkında daha fazla bilgi için, Teknik Borçları Anlama ve Elde Etme 3 Metrik özetini bir araya getirdik .

Düşüncelerin nelerdir? Herhangi bir sorunuza cevap vermekten mutluluk duyarız ve görüşlerinizi duymak için açsınız :).

Hataları ve istenmeyen teknoloji borçlarını önleme mülkiyeti

Mülkiyet mühendislik sağlığının öncü bir göstergesidir.

Kodbazın birçok insandan katkı alan kısımları zaman içinde zalimce biriktirirken, daha az insandan katkıda bulunanlar daha iyi bir durumda olma eğilimindedir. Kodbazın bir kısmı hakkında iyi bilgi sahibi olan sıkı bir grupta yüksek standartları korumak daha kolaydır.

Bu, bazı öngörücü güçler sağlar: Kod tabanının zayıf sahiplerine ait kısımların zaman içinde borç biriktirmesi ve birlikte çalışması giderek zorlaşır. Özellikle, borcun istenmeden üstlenilmesi muhtemeldir eksik bilginin ve kodun kalitesinin seyreltilmiş mülkiyetinin bir yan etkisi olarak, .

Bu müştereklerin trajedisine biraz benziyor .

Mimariyi geliştirmek için uyum

Uyum, iyi tanımlanmış bileşenlerin takip eden bir göstergesidir.

Uyum ve bunun karşılığı olan eşleşme, uzun zamandır, yazılım tasarlarken odaklanılması gereken önemli kavramlar olarak kabul edilmiştir.

Kodun, öğelerinin çoğunun birbirine ait olması durumunda yüksek uyuma sahip olduğu söylenir. Yüksek uyum genel olarak tercih edilir çünkü sürdürülebilirlik, yeniden kullanılabilirlik ve sağlamlık ile ilişkilidir. Yüksek yapışma ve gevşek bağlantı el ele gitme eğilimindedir.

Daha fazla tekrar kullanılabilir ve sürdürülebilir kodla ilişkilendirilmenin ötesinde, yüksek uyum, kod tabanının verimi artıran belirli bir bölümünü değiştirmek için dahil olması gereken kişilerin sayısını da azaltır.

Sorunlu alanları tespit etmek için karma

Güğüm (tekrarlanan aktivite), büyüyen bir sistemde yeniden yapılanma için olgunlaşmış alanların belirlenmesine ve derecelendirilmesine yardımcı olur.

Sistemler büyüdükçe, geliştiricilerin mimarilerini anlamaları zorlaşır. Geliştiricilerin yeni bir özellik sunmak için kod tabanının birçok bölümünü değiştirmek zorunda kalmaları durumunda, hatalara yol açan yan etkileri ortaya koymaktan kaçınmaları zor olacaktır ve daha az üretken olacaklardır çünkü kendilerini daha fazla eleman ve konseptle tanıştırmaları gerekir.

Bu nedenle daha istikrarlı bir sistem oluşturmak ve istenmeyen sonuçlardan kaçınmak için tek bir sorumluluk için çaba sarf etmek önemlidir. Bazı dosyalar mimari merkezler olmasına ve yeni özellikler eklendikçe aktif kalmasına rağmen, dosyalara yakınlık sağlayacak şekilde kod yazmak ve QA karıştırma alanlarını titizlikle incelemek, test etmek ve test etmek iyi bir fikirdir.

Bu aktif dosyaları çalkalayın, böylece kod tabanınızdaki yüzey değişimini azaltmak için parçalarının kırılıp kırılmayacağına karar verebilirsiniz.

Bir böcek avcısı veya bir tür çevik yazılım aracılığıyla iyi bir geçmişiniz varsa, basit tutabilirsiniz. Temel görevleri tamamlamak için harcanan zaman. Ayrıca, projenin şimdiki zamana kıyasla genç olduğu tahminlerin güvenilirliği.