Weiß jemand, ob es irgendeine Art von Werkzeug gibt, um eine Zahl für die technische Verschuldung einer Codebasis als eine Art Codemetrik festzulegen? Wenn nicht, kennt jemand einen Algorithmus oder eine Reihe von Heuristiken dafür?

Wenn keines dieser Dinge bisher existiert, würde ich mich für Ideen interessieren, wie man mit so etwas anfangen kann. Das heißt, wie kann ich die durch eine Methode, eine Klasse, einen Namespace, eine Assembly usw. verursachte technische Verschuldung quantifizieren?

Ich bin am meisten an der Analyse und Bewertung einer C # -Codebasis interessiert, aber ich bitte Sie, sich auch für andere Sprachen einzusetzen, insbesondere wenn die Konzepte sprachenübergreifend sind.

Die technische Verschuldung ist nur eine abstrakte Vorstellung davon, dass bestimmte Entscheidungen im Hinblick auf das Entwerfen, Bauen, Testen und Warten eines Systems so getroffen wurden, dass es schwieriger geworden ist, das Produkt zu testen und zu warten. Wenn Sie mehr technische Schulden haben, wird es schwieriger, ein System weiterzuentwickeln. Entweder müssen Sie sich mit den technischen Schulden auseinandersetzen und immer mehr Zeit für andere einfache Aufgaben aufwenden, oder Sie müssen Ressourcen investieren (Zeit und Kosten) Geld) in die Reduzierung der technischen Schulden durch Refactoring des Codes, die Verbesserung der Tests und so weiter.

Es gibt eine Reihe von Metriken, die Aufschluss über die Qualität des Codes geben können:

• Code-Abdeckung. Es gibt verschiedene Tools , die Ihnen mitteilen, wie viel Prozent Ihrer Funktionen, Anweisungen und Zeilen von Unit-Tests abgedeckt werden. Sie können System- und Abnahmetests auch den Anforderungen zuordnen, um den Prozentsatz der Anforderungen zu bestimmen, die von einem Test auf Systemebene abgedeckt werden. Die angemessene Abdeckung hängt von der Art der Anwendung ab.
• Kopplung und Zusammenhalt . Code mit geringer Kopplung und hoher Kohäsion ist in der Regel leichter zu lesen, zu verstehen und zu testen. Es gibt Codeanalyse-Tools, mit denen das Ausmaß der Kopplung und Kohäsion in einem bestimmten System angegeben werden kann.
• Zyklomatische Komplexität ist die Anzahl der eindeutigen Pfade durch eine Anwendung. Dies wird normalerweise auf Methoden- / Funktionsebene gezählt. Die zyklomatische Komplexität hängt mit der Verständlichkeit und Testbarkeit eines Moduls zusammen. Höhere Werte für die zyklomatische Komplexität weisen nicht nur darauf hin, dass jemand Probleme haben wird, dem Code zu folgen, sondern die zyklomatische Komplexität gibt auch die Anzahl der Testfälle an, die zum Erreichen der Abdeckung erforderlich sind.
• Die verschiedenen Halstead-Komplexitätsmaße geben Aufschluss über die Lesbarkeit des Codes. Diese zählen die Operatoren und Operanden, um das Volumen, den Schwierigkeitsgrad und den Aufwand zu bestimmen. Oft kann dies darauf hinweisen, wie schwierig es für jemanden sein wird, den Code zu erfassen und zu verstehen, häufig in Fällen wie einer Codeüberprüfung oder einem neuen Entwickler der Codebasis.
• Menge des doppelten Codes. Duplizierter Code kann auf potenzielle Umgestaltungen von Methoden hinweisen. Doppelter Code bedeutet, dass mehr Zeilen für einen Fehler eingefügt werden müssen und dass die Wahrscheinlichkeit steigt, dass dieselben Fehler an mehreren Stellen auftreten. Wenn dieselbe Geschäftslogik an mehreren Stellen vorhanden ist, wird es schwieriger, das System so zu aktualisieren, dass Änderungen berücksichtigt werden.

Häufig können statische Analysetools Sie auf potenzielle Probleme hinweisen. Nur weil ein Tool auf ein Problem hinweist, heißt das natürlich nicht, dass es ein Problem gibt - es bedarf menschlicher Beurteilung, um festzustellen, ob irgendetwas später problematisch sein könnte. Diese Metriken geben Ihnen nur die Warnung, dass es an der Zeit ist, ein System oder Modul genauer zu betrachten.

Diese Attribute konzentrieren sich jedoch auf den Code. Sie weisen nicht ohne Weiteres auf technische Mängel in Ihrer Systemarchitektur oder Ihrem Systemdesign hin, die sich auf verschiedene Qualitätsmerkmale beziehen könnten.

Sonar verfügt über eine technische Schuldenheuristik sowie mehrere andere Funktionen, die für ein Softwareprojekt nützlich sind.

Es unterstützt auch eine ziemlich breite Palette von Sprachen.

SonarQube (ehemals Sonar ) ist eine Open-Source-Plattform für die kontinuierliche Überprüfung der Codequalität ...

• Unterstützung für mehr als 25 Sprachen: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL usw.
• SonarQube wird auch in Android Deveopment verwendet.
• Bietet Berichte zu dupliziertem Code, Codierungsstandards, Komponententests, Codeabdeckung, komplexem Code, potenziellen Fehlern, Kommentaren sowie Design und Architektur.
• Zeitmaschine und Differentialansichten.
• Vollautomatische Analysen: Integration in Maven, Ant, Gradle und kontinuierliche Integrationstools (Atlassian Bamboo, Jenkins, Hudson usw.).
• Integriert sich in die Eclipse-Entwicklungsumgebung
• Integration mit externen Tools: JIRA, Mantis, LDAP, Fortify usw.
• Erweiterbar mit Plugins.
• Implementiert die SQALE- Methode zur Berechnung der technischen ...

Ich hasse es, eine Analogie aus dem Finanzbereich zu verwenden, aber sie scheint wirklich angemessen zu sein. Wenn Sie einen Preis festlegen (Vermögenswerte jeglicher Art), kann dieser sowohl einen inneren als auch einen äußeren Wert haben. In diesem Fall hat der existierende Code einen inneren Wert, der eine Menge ist, die der relativen Qualität des Codes entspricht, und er hätte auch einen äußeren Wert (Wert von dem, was mit dem Code gemacht werden könnte), und diese Mengen wären additiv. Der innere Wert kann mithilfe der von Ihnen zur Bewertung des Codes verwendeten Methode (+5 für Kommentare / Lesbarkeit, -10 für Codeabdeckung usw.) in Gutschriften und Abbuchungen (gut oder schlecht) unterteilt werden.

Ich kenne sicherlich keine Tools, die dies heute quantifizieren, und ich denke, Sie hätten eine völlig neue Diskussion, wenn Sie die Vorzüge verschiedener Strategien zur "Schuldenbewertung" diskutieren, aber ich stimme Matthew zu - die Schuld ist die Schuld Die kumulativen Kosten für den Erhalt des Codes, so gut Sie ihn erhalten können, richten sich nach der Methode, die Sie verwenden, um die Arbeitsstunden, die erforderlich sind, um dorthin zu gelangen, zu kalkulieren.

Eine weitere Überlegung ist, dass es mit Sicherheit ein Maß für die Kosteneffizienz gibt, bei dem der Wert einer für die Codebasis aufgewendeten Stunde bei Annäherung an "Perfektion" mehr als wahrscheinlich exponentiell abnimmt, sodass wahrscheinlich ein zusätzliches Optimierungsproblem vorliegt Maximieren Sie den Nutzen der geleisteten Arbeit.

Zwischen den Entwicklern scheinen WTFs / Minute ein ziemlich zuverlässiges Maß für die technische Verschuldung zu sein .

_{Das Problem mit dieser "Metrik" ist, dass es normalerweise ziemlich schwierig ist, "außerhalb" zu kommunizieren.}

Die Metrik, die für mich bei der Kommunikation der technischen Schulden an "Außenstehende" funktioniert hat, war die Menge an Test- und Fehlerbehebungsaufwand (insbesondere zur Behebung von Regressionsfehlern ), die für eine erfolgreiche Zustellung erforderlich waren.

Ein Wort der Vorsicht: Obwohl dieser Ansatz ziemlich leistungsfähig ist, sollten Sie ihn besser mit guten alten WTFs / Minute überprüfen, bevor Sie darauf zurückgreifen. Die Sache ist, es ist ziemlich umständlich: Um die Daten zu erhalten, muss man die Zeit sorgfältig verfolgen und sie genau nach den entsprechenden Kategorien protokollieren.

• es ist so viel einfacher zu Zustand 3 Wochen insgesamt bei der Umsetzung Merkmal A verbrachte als
   
  ich 14 Stunden auf Entwurf Umsetzung der Funktion A dann 29 Stunden auf Rauchtest verbrachte sie dann 11 Stunden auf Updates für Regressionen Umsetzung entdeckte ich, dann 18 Stunden die QA - Tests -bereite Feature-Implementierung. Danach haben die QA-Mitarbeiter 17 Stunden damit verbracht, die erste Kandidatenversion zu testen. Danach analysierte ich 13 Stunden lang die von QA für die erste Kandidatenversion eingereichten Fehler und implementierte 3 Stunden lang die Fehlerbehebungen. Danach verbrachte ich 11 Stunden mit dem Testen der Änderungen, die ich an der ersten Kandidatenfreigabe vorgenommen hatte. Nachdem...

Wie auch immer, Daten über das Testen und das Beheben von Fehlern waren meiner Erfahrung nach recht einfach zu übermitteln.

In der letzten Version haben wir ungefähr 90% der Zeit damit verbracht, Regressionsfehler zu testen und zu beheben. Schlagen Sie für die nächste Version vor, einige Anstrengungen zu unternehmen, um diesen Wert auf 60-70% zu senken.

Noch ein Wort zur Vorsicht. Daten wie die oben genannten von 90% könnten nicht nur als Hinweis auf die technische Verschuldung interpretiert werden, sondern auch (überraschend überraschend) als Hinweis darauf, dass einer der Befragten die Programmierung / bestimmte Technologie nicht gut beherrscht. Msgstr "Sie machen einfach zu viele Fehler in Ihrem Code".

Wenn die Gefahr besteht, dass Daten auf diese Weise falsch interpretiert werden, ist es hilfreich, zusätzliche Referenzdaten zu etwas zu haben, mit dem weniger WTF verglichen werden kann.

• Sprich , wenn es zwei ähnliche Komponenten / Anwendungen , die von gleichen Entwickler beibehalten (s), erste Freigabe auf der „waste Rate“ etwa 50% und die zweite bei 80-90, macht dies ein ziemlich starkes Argument zugunsten der zweiten Wesen Gegenstand technischer Schulden.

Wenn an dem Projekt engagierte Tester beteiligt sind, können sie auch zu einer objektiveren Auswertung der Daten beitragen. Wie ich in einer anderen Antwort erwähnt habe ,

Mit Testern erhalten Sie jemanden, der Ihr Verständnis für Designprobleme unterstützt. Wenn sich nur Entwickler über die Codequalität beschweren , klingt dies oft nach subjektiven WTFs hinter der geschlossenen Tür .
 
Aber wenn dies von einem QA-Mitarbeiter wiederholt wird, der behauptet, component A100 Regressionsfehler für 10 neue Funktionen component Bgehabt zu haben , wird Kommunikation plötzlich zu einem ganz anderen Spiel.

Ich denke, die Frage ist, wie viel es kosten würde, Ihre technischen Schulden "zurückzukaufen" - das heißt, wie viel Arbeit ist es, sie zu reparieren? Nun, es liegt an der Mannschaft, das herauszufinden.

Während der Sprintplanung fordere ich das Team auf, die Komplexität der Reparatur von technischen Schuldtiteln auf die gleiche Weise einzuschätzen, wie sie die Komplexität einer User Story einschätzen würden. An diesem Punkt ist es ein Verhandlungsspiel zwischen dem Team und dem Produktbesitzer, um zu bestimmen, welche technischen Schulden im aktuellen Sprint mit ausreichend hoher Priorität zu erledigen sind (um tatsächliche User Storys zu verdrängen) und was warten kann.

Wenn Sie kein Gedränge machen, halte ich mich an meine Prämisse - die technischen Schulden sollten an den Kosten des Mittels gemessen werden.

Es gibt eine ziemlich starke Plattform namens CASTtechnische Schulden in großen Anwendungen zu suchen. Wir haben es in einem Projekt verwendet, in dem wir eine große Verbesserung eines Legacy-Systems übernommen haben. Es sagt Ihnen nicht, was in den Köpfen der Leute war, die den Code geschrieben haben, aber es untersucht den Code und findet Code- und Architekturfehler und quantifiziert sich dann zu technischen Schulden, wenn Sie möchten. Die eigentliche Verwendung bei der Betrachtung ist jedoch nicht der Betrag von $, sondern die Liste der Probleme, die bereits im Code enthalten sind. Dies sagt Ihnen etwas über einen Teil Ihrer technischen Schulden aus (daher bin ich mit einigen der Antworten oben nicht einverstanden). Es gibt einige technische Probleme, die ausschließlich auf Design basieren und die sehr subjektiv sind - wie Pornografie - Sie kennen sie, wenn Sie sie sehen und den Kontext kennen. Ich würde streiten, ob das wirklich "technische" Schulden sind. Es gibt einige technische Schulden, die nur in der Implementierung liegen, und ich glaube, dass

Hier ist ein Webinar des MIT, das die Forschung zu technischen Schulden in großen Softwaresystemen beschreibt: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Die Autoren schrieben Code, um ein Projekt zu analysieren und Metriken zur Komplexität der Architektur zu ermitteln. Es wurde gezeigt, dass diese Metriken in engem Zusammenhang mit der Fehlerdichte, der Entwicklerproduktivität und der Fluktuation des Entwicklungspersonals stehen.

Die im Webinar beschriebene Arbeit baut auf der Modularitätsforschung auf, die Alan MacCormack und Carliss Baldwin an der Harvard Business School durchgeführt haben. Ich würde mir auch ihre Papiere ansehen. Ihre "Vermehrungskosten" könnten genau das sein, wonach Sie suchen.

Ich würde sagen, dass die Standardcodemetriken als allgemeine relative Ansicht der technischen Verschuldung verwendet werden können. VS Ultimate enthält einen Code Analyzer, mit dem Sie einen "Wartbarkeitsindex" erhalten, der auf zyklomatischer Komplexität, Kopplung, LoC und Vererbungstiefe basiert. Sie können in alle Problembereiche eintauchen und Details anzeigen (bis zur Funktionsebene). Ich habe es gerade in meinem Projekt ausgeführt und die niedrigsten Punktzahlen, die wir erhalten haben, waren 69 in unserem Datenpaket (Konfigurieren und Initialisieren von EF) und unserer Testsuite. Alles andere war 90 oder höher. Es gibt andere Tools, mit denen Sie mehr Kennzahlen erhalten, als in Onkel Bobs PPP beschrieben

Ich würde mir technische Schulden nicht als Dollars vorstellen, für deren Quantifizierung Sie ein ausgefallenes Modell benötigen. Ich würde es als einen Gefallen betrachten. Wenn Ihnen jemand einen Gefallen tut und Sie ihn wahrscheinlich vergessen, schreiben Sie ihn auf. Wenn Sie eine Abkürzung nehmen, schreiben Sie sie auf. Dies hilft Ihnen, sich zu erinnern, und macht Sie ohnmächtiger, es anzuerkennen. Es wird kein ausgefallenes Werkzeug benötigt. Notepad oder Ecxel können den Trick machen.

Ich arbeite für ein Unternehmen, das sich genau darum kümmert. Im Folgenden finden Sie 3 umsetzbare Messgrößen, die Sie bei der Bewältigung technischer Schulden berücksichtigen sollten. Für weitere Informationen zu "Wie" und "Wann", um sie zu verfolgen, haben wir einen zusammenfassenden Artikel 3 Metriken zum Verständnis und zur Bewältigung der technischen Schulden zusammengestellt .

Was sind deine Gedanken? Gerne beantworten wir Ihre Fragen und freuen uns auf Ihr Feedback :).

Eigentum zur Vermeidung von Mängeln und unerwünschten technischen Schulden

Eigentum ist ein führender Indikator für die technische Gesundheit.

Die Teile der Codebasis, die Beiträge von vielen Menschen erhalten, häufen sich im Laufe der Zeit an, während diejenigen, die Beiträge von weniger Menschen erhalten, in der Regel in einem besseren Zustand sind. Es ist einfacher, hohe Standards in einer engen Gruppe aufrechtzuerhalten, die über ihren Teil der Codebasis gut informiert ist.

Dies bietet eine gewisse Vorhersagekraft: In schwach besessenen Teilen der Codebasis werden sich mit der Zeit wahrscheinlich Schulden ansammeln und es wird zunehmend schwieriger, mit ihnen zu arbeiten. Insbesondere ist es wahrscheinlich, dass Schulden unbeabsichtigt aufgenommen werden , einfach als Nebeneffekt unvollständiger Informationen und verwässerter Eigentumsverhältnisse an der Qualität des Codes.

Dies ist etwas analog zur Tragödie der Commons .

Zusammenhalt zur Verbesserung der Architektur

Kohäsion ist ein nachlaufender Indikator für genau definierte Komponenten.

Der Zusammenhalt und sein Gegenstück, die Kopplung, sind seit langem als wichtige Konzepte für die Entwicklung von Software anerkannt.

Code soll eine hohe Kohäsion haben, wenn die meisten seiner Elemente zusammengehören. Eine hohe Kohäsion ist im Allgemeinen vorzuziehen, da sie mit Wartbarkeit, Wiederverwendbarkeit und Robustheit verbunden ist. Hohe Kohäsion und lose Kopplung gehen in der Regel Hand in Hand.

Hohe Kohäsion ist nicht nur mit wiederverwendbarem und wartbarem Code verbunden, sondern minimiert auch die Anzahl der Personen, die einbezogen werden müssen, um einen bestimmten Teil der Codebasis zu ändern, was die Produktivität erhöht.

Abwandern, um Problembereiche zu identifizieren

Abwanderung (wiederholte Aktivität) hilft dabei, Bereiche zu identifizieren und zu klassifizieren, die für die Umgestaltung in einem wachsenden System reif sind.

Mit zunehmendem Systemwachstum wird es für Entwickler schwieriger, ihre Architektur zu verstehen. Wenn Entwickler viele Teile der Codebasis ändern müssen, um eine neue Funktion bereitzustellen, ist es für sie schwierig, Nebenwirkungen zu vermeiden, die zu Fehlern führen, und sie sind weniger produktiv, da sie sich mit mehr Elementen und Konzepten vertraut machen müssen.

Aus diesem Grund ist es wichtig, sich um die einheitliche Verantwortung zu bemühen, um ein stabileres System zu schaffen und unbeabsichtigte Konsequenzen zu vermeiden. Einige Dateien sind zwar Architektur-Hubs und bleiben aktiv, wenn neue Funktionen hinzugefügt werden. Es empfiehlt sich jedoch, den Code so zu schreiben, dass die Dateien geschlossen werden, und Bereiche, die ständig überprüft, getestet und auf den neuesten Stand gebracht werden, genau zu prüfen.

Churn taucht diese aktiven Dateien auf, damit Sie entscheiden können, ob sie aufgeteilt werden sollen, um den Änderungsbereich in Ihrer Codebasis zu verringern.

Wenn Sie eine gute Geschichte über einen Bugtracker oder eine agile Software haben, können Sie diese einfach halten. Zeitaufwand für die Ausführung grundlegender Aufgaben. Auch die Zuverlässigkeit von Schätzungen, als das Projekt noch jung war.