Was fasziniert Sie an Codemetriken? [geschlossen]

Ich habe in letzter Zeit eine Reihe von Fragen zu SO-Metriken zu SO gesehen und muss mich fragen, was die Faszination ist. Hier sind einige aktuelle Beispiele:

• Welche Code-Metriken überzeugen Sie davon, dass der bereitgestellte Code beschissen ist?
• Wann immer, wenn überhaupt, ist die Anzahl der Codezeilen eine nützliche Metrik
• Qualitätsprüfungen schreiben

In meinen Augen kann jedoch keine Metrik eine Codeüberprüfung ersetzen:

• Einige Metriken geben manchmal Orte an, die überprüft werden müssen, und
• Radikale Änderungen der Metriken über kurze Zeiträume können auf Orte hinweisen, die überprüft werden müssen

Aber ich kann mir keine einzige Metrik vorstellen, die für sich genommen immer "guten" oder "schlechten" Code anzeigt - es gibt immer Ausnahmen und Gründe für Dinge, die die Messungen nicht sehen können.

Gibt es magische Erkenntnisse aus Code-Metriken, die ich übersehen habe? Suchen faule Programmierer / Manager nach Ausreden, um keinen Code zu lesen? Werden Menschen mit riesigen Legacy-Codebasen konfrontiert und suchen sie nach einem Ausgangspunkt? Was ist los?

Hinweis: Ich habe einige dieser Fragen zu den spezifischen Themen sowohl in Antworten als auch in Kommentaren gestellt und keine Antworten erhalten. Daher dachte ich, ich sollte die Community im Allgemeinen fragen, da mir möglicherweise etwas fehlt. Es wäre schön, einen Metrik-Batch-Job auszuführen und den Code anderer Leute (oder meinen eigenen) nie wieder lesen zu müssen. Ich halte das einfach nicht für praktisch!

EDIT: Ich bin mit den meisten, wenn nicht allen diskutierten Metriken vertraut. Ich sehe den Sinn dieser Metriken einfach nicht isoliert oder als willkürliche Qualitätsstandards.

Die Antworten in diesem Thread sind seltsam, da sie von folgenden Themen sprechen:

• "das Team", wie "der einzige Nutznießer" dieser Metriken;
• "die Metriken", als ob sie irgendetwas an sich bedeuten.

1 / Metriken gelten nicht für eine Population, sondern für drei :

• Entwickler: Sie befassen sich mit sofortigen statischen Codemetriken hinsichtlich der statischen Analyse ihres Codes (zyklomatische Komplexität, Kommentarqualität, Anzahl der Zeilen, ...).
• Projektleiter: Sie befassen sich mit täglichen Live-Code-Metriken, die aus Unit-Tests, Codeabdeckung und kontinuierlichen Integrationstests stammen
• Geschäftssponsoren (sie werden immer vergessen, aber sie sind die Stakeholder, die für die Entwicklung bezahlen): Sie befassen sich mit wöchentlichen globalen Codemetriken in Bezug auf Architekturdesign, Sicherheit, Abhängigkeiten, ...

Alle diese Metriken können natürlich von allen drei Populationen beobachtet und analysiert werden, aber jede Art ist so konzipiert, dass sie von jeder bestimmten Gruppe besser verwendet werden kann.

2 / Metriken stellen für sich genommen eine Momentaufnahme des Codes dar, und das bedeutet ... nichts!

Es ist die Kombination dieser Metriken und die Kombinationen dieser verschiedenen Analyseebenen, die auf einen "guten" oder "schlechten" Code hinweisen können, aber was noch wichtiger ist, es ist der Trend dieser Metriken , der signifikant ist.

Dies ist die Wiederholung dieser Metriken, die den tatsächlichen Mehrwert bieten, da sie den Geschäftsmanagern / Projektleitern / Entwicklern helfen, Prioritäten unter den verschiedenen möglichen Codekorrekturen zu setzen

Mit anderen Worten, Ihre Frage nach der "Faszination von Metriken" könnte sich auf den Unterschied beziehen zwischen:

• "schöner" Code (obwohl das immer im Auge des Betrachter-Kodierers liegt)
• "guter" Code (der funktioniert und beweisen kann, dass er funktioniert)

So könnte beispielsweise eine Funktion mit einer zyklomatischen Komplexität von 9 als "schön" definiert werden, im Gegensatz zu einer langen gewundenen Funktion der zyklomatischen Komplexität von 42.

Aber falls:

• Die letztere Funktion hat eine stetige Komplexität, kombiniert mit einer Codeabdeckung von 95%.
• Ersteres weist eine zunehmende Komplexität auf, kombiniert mit einer Abdeckung von ... 0%,

man könnte argumentieren:

• Letzteres stellt einen " guten " Code dar (es funktioniert, es ist stabil, und wenn es geändert werden muss, kann man überprüfen, ob es nach Änderungen noch funktioniert).
• Ersteres ist ein " schlechter " Code (es müssen noch einige Fälle und Bedingungen hinzugefügt werden, um alles abzudecken, was zu tun ist, und es gibt keine einfache Möglichkeit, einen Regressionstest durchzuführen).

Um es zusammenzufassen:

eine einzelne Metrik, die für sich genommen immer [...]

: nicht viel, außer dass der Code "schöner" sein kann, was an sich nicht viel bedeutet ...

Gibt es magische Erkenntnisse aus Code-Metriken, die ich übersehen habe?

Nur die Kombination und der Trend von Metriken geben den wirklichen "magischen Einblick", den Sie suchen.

Ich hatte ein Projekt, das ich vor einem Monat als Ein-Personen-Job durchgeführt habe, gemessen an der zyklomatischen Komplexität. Das war meine erste Begegnung mit solchen Metriken.

Der erste Bericht, den ich bekam, war schockierend. Fast alle meine Funktionen haben den Test nicht bestanden, auch die (imho) sehr einfachen. Ich habe die Komplexität umgangen, indem ich logische Unteraufgaben in Unterprogramme verschoben habe, auch wenn sie nur einmal aufgerufen wurden.

Für die andere Hälfte der Routinen setzte mein Stolz als Programmierer ein und ich versuchte, sie so umzuschreiben, dass sie dasselbe tun, nur einfacher und lesbarer. Das hat funktioniert und ich konnte die yclomatische Komplexitätsschwelle des Kunden am besten erreichen.

Am Ende konnte ich fast immer eine bessere Lösung und viel saubereren Code finden. Die Leistung hat nicht darunter gelitten (vertrau mir - ich bin paranoid und überprüfe die Demontage der Compiler-Ausgabe ziemlich oft).

Ich denke, Metriken sind eine gute Sache, wenn Sie sie als Grund / Motivation zur Verbesserung Ihres Codes verwenden. Es ist jedoch wichtig zu wissen, wann Sie anhalten und einen Zuschuss für eine Metrikverletzung beantragen müssen.

Metriken sind Leitfäden und Hilfen, nicht Selbstzweck.

Die beste Metrik, die ich jemals verwendet habe, ist der CRAP-Score .

Grundsätzlich handelt es sich um einen Algorithmus, der die gewichtete zyklomatische Komplexität mit der automatisierten Testabdeckung vergleicht. Der Algorithmus sieht folgendermaßen aus: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) wobei comp (m) die zyklomatische Komplexität der Methode m ist und cov (m) die Testcodeabdeckung ist, die durch automatisierte Tests bereitgestellt wird.

Die Autoren des oben genannten Artikels (bitte lesen Sie ihn ... es ist Ihre Zeit wert) schlagen einen maximalen CRAP-Wert von 30 vor, der sich wie folgt aufteilt:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

Wie Sie schnell sehen, belohnt die Metrik das Schreiben von Code, der nicht komplex ist, gepaart mit einer guten Testabdeckung (wenn Sie Komponententests schreiben und dies auch sein sollten und nicht messen ... Nun, Sie würden wahrscheinlich gerne in den Wind spucken auch). ;-);

Für die meisten meiner Entwicklungsteams habe ich mich sehr bemüht, den CRAP-Wert unter 8 zu bringen, aber wenn sie gültige Gründe hatten, um die zusätzliche Komplexität zu rechtfertigen, war dies akzeptabel, solange sie die Komplexität mit ausreichenden Tests abdeckten. (Das Schreiben von komplexem Code ist immer sehr schwierig zu testen ... ein versteckter Vorteil dieser Metrik).

Den meisten Menschen fiel es anfangs schwer, Code zu schreiben, der die CRAP-Punktzahl erreicht. Aber im Laufe der Zeit haben sie besseren Code geschrieben, Code, der weniger Probleme hatte, und Code, der viel einfacher zu debuggen war. Von jeder Metrik ist dies diejenige, die die wenigsten Bedenken und den größten Nutzen hat.

Eine gute Codeüberprüfung ist kein Ersatz für ein gutes statisches Analysewerkzeug, das natürlich keinen guten Satz von Komponententests ersetzt. Jetzt sind Komponententests ohne einen Satz von Abnahmetests nicht mehr gut.

Codemetriken sind ein weiteres Werkzeug, das Sie in Ihre Toolbox einfügen können. Sie sind keine eigenständige Lösung. Sie sind lediglich ein geeignetes Werkzeug (natürlich mit allen anderen Tools in Ihrer Box!).

Für mich ist die wichtigste Metrik, die schlechten Code identifiziert, die zyklomatische Komplexität. Fast alle Methoden in meinen Projekten liegen unter CC 10 und Fehler treten immer in älteren Methoden mit CC über 30 auf. Ein hoher CC zeigt normalerweise Folgendes an:

• in Eile geschriebener Code (dh es war keine Zeit, eine elegante Lösung zu finden, und nicht, weil das Problem eine komplexe Lösung erforderte)
• ungetesteter Code (niemand schreibt Tests für solche Bestien)
• Code, der mehrfach gepatcht und repariert wurde (dh mit ifs und todo-Kommentaren durchsetzt)
• ein Hauptziel für das Refactoring

Die Menschen fühlen sich von der Idee mechanistischer Wege angezogen, Code zu verstehen und zu beschreiben. Wenn ja, denken Sie an die Auswirkungen auf Effizienz und Produktivität!

Ich stimme zu, dass eine Metrik für "Code-Güte" ungefähr so ​​sinnvoll ist wie eine Metrik für "gute Prosa". Dies bedeutet jedoch nicht, dass Metriken nutzlos sind, sondern möglicherweise missbraucht werden.

Beispielsweise weisen Extremwerte für einige Metriken den Weg zu möglichen Problemen. Eine 1000 Zeilen lange Methode ist wahrscheinlich nicht wartbar. Code mit Null-Einheitentest-Code-Abdeckung weist wahrscheinlich mehr Fehler auf als ähnlicher Code mit vielen Tests. Ein großer Code-Sprung, der einem Projekt kurz vor der Veröffentlichung hinzugefügt wurde und keine Bibliothek eines Drittanbieters ist, sorgt wahrscheinlich für zusätzliche Aufmerksamkeit.

Ich denke, wenn wir Metriken als Vorschlag verwenden - eine rote Fahne - können sie vielleicht nützlich sein. Das Problem ist, wenn Menschen anfangen, die Produktivität in SLOC oder die Qualität in Prozent der Zeilen mit Tests zu messen.

Meine höchst subjektive Meinung ist, dass Codemetriken die unwiderstehliche institutionelle Faszination ausdrücken, etwas quantifizieren zu können, das von Natur aus nicht quantifizierbar ist.

In gewisser Weise zumindest psychologisch sinnvoll - wie können Sie Entscheidungen über etwas treffen, das Sie nicht bewerten oder verstehen können? Letztendlich können Sie die Qualität natürlich nur bewerten, wenn Sie sich mit dem Thema auskennen (und mindestens so gut sind wie das, was Sie bewerten möchten) oder jemanden fragen, der sich auskennt, was das Problem natürlich nur zurückbringt ein Schritt.

In diesem Sinne wäre es vielleicht eine vernünftige Analogie, Studienanfänger nach SAT-Ergebnissen zu bewerten. Es ist unfair und übersieht jede Art von Subtilität, aber wenn Sie quantifizieren müssen, müssen Sie etwas tun.

Ich sage nicht, dass ich denke, dass es eine gute Maßnahme ist, nur dass ich die intitutionelle Unwiderstehlichkeit davon sehen kann. Und wie Sie bereits betont haben, gibt es wahrscheinlich ein paar vernünftige Metriken (viele mehr als 500 Linienmethoden, hohe Komplexität - wahrscheinlich schlecht). Ich war jedoch noch nie an einem Ort, an dem ich mich darauf eingelassen habe.

Es gibt eine Codemetrik, an die ich glaube.

Ich arbeite an einem großen System. Wenn eine einzelne neue Anforderung zu mir kommt, habe ich mich daran gemacht, sie zu codieren. Wenn ich fertig bin und die Fehler behoben habe, checke ich sie in das Versionskontrollsystem ein. Dieses System macht einen Unterschied und zählt alle Änderungen auf, die ich vorgenommen habe.

Je kleiner diese Zahl ist, desto besser.

Metriken und automatisierte Tests sind kein Ersatz für vollständige Codeüberprüfungen.

Sie beschleunigen nur die Dinge. Mit einem automatisierten Prüfer können Sie sehr leicht erkennen, welche Konventionen Sie vergessen haben, dass Sie die angegebenen Pakete und Methoden verwenden usw. Sie können sehen, was Sie beheben können, ohne die Zeit anderer zu nutzen.

Manager mögen Metriken auch, weil sie das Gefühl haben, eine genaue Zahl für die Produktivität zu erhalten (obwohl dies oft nicht der Fall ist) und sie in der Lage sein sollten, Menschen besser zu jonglieren.

Messungen sind nur nützlich, wenn:

• Das Team hat sie entwickelt
• Das Team stimmte ihnen zu
• Sie werden verwendet, um einen bestimmten Bereich zu identifizieren

Im Allgemeinen leidet jede Metrik, die nicht dazu passt, unter der Optimierung des Teams. Sie möchten Codezeilen messen? Meine Güte, sehen Sie, wie viele sie schreiben können! Sie möchten die Codeabdeckung messen, indem Sie golly beobachten, wie ich diesen Code abdecke!

Ich denke, Metriken können nützlich sein, um Trends zu identifizieren, und tatsächlich habe ich einige nützliche gesehen, wie das Plotten, wenn der Build unterbrochen wird, die Code-Abwanderung (Anzahl der Codezeilen, die sich während des Projekts ändern) und andere Dinge. Aber wenn das Team nicht auf sie kommt oder sie ihnen nicht zustimmen oder sie nicht verstehen, befinden Sie sich wahrscheinlich in einer Welt voller Verletzungen.

Hier sind einige Komplexitätsmetriken von stan4j .

Ein Tool zur Analyse der Eclipse-Klassenstruktur.

Ich mag dieses Tool und die Metriken. Ich behandle die Metriken als Statistiken, Indikatoren, Warnmeldungen. Aufgrund einiger Methoden oder Klassen hat eine komplizierte Logik sie manchmal komplex gemacht. Was zu tun ist, ist, sie im Auge zu behalten, sie zu überprüfen, um festzustellen, ob es notwendig ist, sie zu überarbeiten oder sie sorgfältig zu überprüfen, was normalerweise der Fall ist Sie sind fehleranfällig. Ich benutze es auch als Analysewerkzeug, um Quellcode zu lernen, da ich gerne von komplex bis einfach lerne. Tatsächlich enthält es einige andere Metriken wie Robert C. Martin Metriken, Chidamber & Kemerer Metriken, Count Metrics. Aber ich mag diese am besten

Komplexitätsmetriken

Zyklomatische Komplexitätsmetriken

Zyklomatische Komplexität (CC) Die zyklomatische Komplexität einer Methode ist die Anzahl der Entscheidungspunkte im Kontrollflussdiagramm der Methode, die um eins erhöht werden. Entscheidungspunkte treten bei if / for / while-Anweisungen, case / catch-Klauseln und ähnlichen Quellcodeelementen auf, bei denen der Kontrollfluss nicht nur linear ist. Die Anzahl der (Bytecode-) Entscheidungspunkte, die durch eine einzelne (Quellcode-) Anweisung eingeführt werden, kann variieren, z. B. abhängig von der Komplexität der Booleschen Ausdrücke. Je höher der zyklomatische Komplexitätswert einer Methode ist, desto mehr Testfälle sind erforderlich, um alle Zweige des Kontrollflussdiagramms der Methode zu testen.

Durchschnittliche zyklomatische Komplexität Durchschnittlicher Wert der Metrik für die zyklomatische Komplexität über alle Methoden einer Anwendung, Bibliothek, eines Paketbaums oder eines Pakets.

Fettmetriken Die Fettmetrik eines Artefakts ist die Anzahl der Kanten in einem geeigneten Abhängigkeitsdiagramm des Artefakts. Der Abhängigkeitsdiagrammtyp hängt von der Metrikvariante und dem ausgewählten Artefakt ab:

Fett Die Fettmetrik einer Anwendung, Bibliothek oder eines Paketbaums ist die Kantenanzahl des Teilbaum-Abhängigkeitsdiagramms. Dieses Diagramm enthält alle untergeordneten Elemente des Artefakts in der Paketbaumhierarchie und damit auch Blattpakete. (Um das entsprechende Diagramm in der Kompositionsansicht anzuzeigen, muss das Umschalten der Flat Packages des Struktur-Explorers deaktiviert werden. Das Umschalten von Bibliotheken anzeigen muss aktiviert sein, wenn das ausgewählte Artefakt eine Bibliothek ist, andernfalls muss es deaktiviert werden.)

Die Fettmetrik eines Pakets ist die Kantenanzahl seines Einheitenabhängigkeitsgraphen. Dieses Diagramm enthält alle Klassen der obersten Ebene des Pakets.

Die Fettmetrik einer Klasse ist die Kantenanzahl ihres Mitgliedsdiagramms. Dieses Diagramm enthält alle Felder, Methoden und Elementklassen der Klasse. (Dieses Diagramm und der Fettwert sind nur verfügbar, wenn die Code-Analyse mit dem Detailgrad-Mitglied und nicht mit der Klasse durchgeführt wurde.)

Fett für Bibliothek Abhängigkeiten (Fat - Bibliotheken) The Fat für Bibliothek Abhängigkeiten Metrik einer Anwendung ist der Flankenzählwert seiner Bibliothek Abhängigkeitsgraphen. Dieses Diagramm enthält alle Bibliotheken der Anwendung. (Um das entsprechende Diagramm in der Kompositionsansicht anzuzeigen, muss der Schalter "Bibliotheken anzeigen" des Struktur-Explorers aktiviert sein.)

Fett für flache Paketabhängigkeiten (Fett - Pakete) Die Metrik Fett für flache Paketabhängigkeiten einer Anwendung ist die Kantenanzahl ihres Diagramms für flache Paketabhängigkeiten. Dieses Diagramm enthält alle Pakete der Anwendung. (Um das entsprechende Diagramm in der Kompositionsansicht anzuzeigen, muss der Schalter für flache Pakete des Struktur-Explorers aktiviert und der Schalter für das Anzeigen von Bibliotheken deaktiviert sein.)

Die Metrik Fett für flache Paketabhängigkeiten einer Bibliothek ist die Kantenanzahl ihres Diagramms für die flache Paketabhängigkeit. Dieses Diagramm enthält alle Pakete der Bibliothek. (Um das entsprechende Diagramm in der Kompositionsansicht anzuzeigen, müssen die Schaltflächen Flat Packages und Show Libraries des Struktur-Explorers aktiviert sein.)

Fett für Klassenabhängigkeiten der obersten Ebene (Fett - Einheiten) Die Metrik Fett für Klassenabhängigkeiten der obersten Ebene einer Anwendung oder Bibliothek ist die Kantenanzahl ihres Einheitsabhängigkeitsdiagramms. Dieses Diagramm enthält alle Klassen der obersten Ebene der Anwendung oder Bibliothek. (Für sinnvolle Anwendungen ist es zu groß, um visualisiert zu werden, und kann daher nicht in der Zusammensetzungsansicht angezeigt werden. Einheitenabhängigkeitsdiagramme werden möglicherweise nur für Pakete angezeigt.)

Metriken können nützlich sein, um die Verbesserung oder Verschlechterung in einem Projekt zu bestimmen, und können sicherlich Verstöße gegen Stil und Konventionen feststellen, aber es gibt keinen Ersatz für Peer-Code-Überprüfungen. Ohne sie können Sie die Qualität Ihres Codes unmöglich kennen.

Oh ... und dies setzt voraus, dass mindestens einer der Teilnehmer an Ihrer Codeüberprüfung eine Ahnung hat.

Ich stimme Ihnen zu, dass Codemetriken keine Codeüberprüfung ersetzen sollten, aber ich glaube, dass sie Codeüberprüfungen ergänzen sollten. Ich denke, es kommt auf das alte Sprichwort zurück: "Sie können nicht verbessern, was Sie nicht messen können." Code-Metriken können dem Entwicklungsteam quantifizierbare "Code-Gerüche" oder Muster liefern, die möglicherweise weiter untersucht werden müssen. Die Metriken, die in den meisten statischen Analysewerkzeugen erfasst werden, sind in der Regel Metriken, die im Laufe der Forschung in der kurzen Geschichte unseres Fachgebiets identifiziert wurden, um eine signifikante Bedeutung zu haben.

Metriken sind kein Ersatz für die Codeüberprüfung, aber weitaus billiger. Sie sind mehr als alles andere ein Indikator.

Ein Teil der Antwort ist, dass einige Codemetriken Ihnen einen sehr schnellen ersten Einblick in die Antwort auf die Frage geben können: Wie ist dieser Code?

Sogar 'Codezeilen' können Ihnen eine Vorstellung von der Größe der Codebasis geben, die Sie betrachten.

Wie in einer anderen Antwort erwähnt, liefert Ihnen der Trend der Metriken die meisten Informationen.

Metriken für sich sind nicht besonders interessant. Es kommt darauf an, was du mit ihnen machst.

Wenn Sie beispielsweise die Anzahl der Kommentare pro Codezeile messen würden, was würden Sie als guten Wert betrachten? Wer weiß? Oder was vielleicht noch wichtiger ist, jeder hat seine eigene Meinung.

Wenn Sie nun genügend Informationen sammeln, um die Anzahl der Kommentare pro Codezeile mit der Zeit zu korrelieren, die zum Beheben eines Fehlers benötigt wird, oder mit der Anzahl der gefundenen Fehler, die der Codierung zugeordnet sind, finden Sie möglicherweise eine empirisch nützliche Anzahl .

Es gibt keinen Unterschied zwischen der Verwendung von Metriken in Software und der Verwendung eines anderen Leistungsmaßes für einen anderen Prozess - zuerst messen Sie, dann analysieren Sie, dann verbessern Sie den Prozess. Wenn Sie nur messen, verschwenden Sie Ihre Zeit.

edit: Als Antwort auf Steven A. Lowes Kommentare - das ist absolut richtig. Bei jeder Datenanalyse muss darauf geachtet werden, zwischen einem Kausalzusammenhang und einer bloßen Korrelation zu unterscheiden. Und die Auswahl der Metriken auf der Grundlage der Eignung ist wichtig. Es macht keinen Sinn, den Kaffeekonsum zu messen und die Codequalität zuzuordnen (obwohl ich sicher bin, dass einige es versucht haben ;-))

Aber bevor Sie die Beziehung finden können (kausal oder nicht), müssen Sie die Daten haben.

Die Auswahl der zu erfassenden Daten hängt davon ab, welchen Prozess Sie überprüfen oder verbessern möchten. Wenn Sie beispielsweise versuchen, den Erfolg Ihrer Codeüberprüfungsverfahren zu analysieren (unter Verwendung Ihrer eigenen Definition für "Erfolg", sei es reduzierte Fehler oder reduzierte Codierungsfehler oder kürzere Durchlaufzeiten oder was auch immer), wählen Sie Metriken aus, die messen die Gesamtrate der Fehler und die Fehlerrate im überprüften Code.

Bevor Sie also die Daten sammeln, müssen Sie wissen, was Sie damit machen möchten. Wenn Metriken das Mittel sind, was ist der Zweck?

Ich halte kleine Änderungen an Metriken nicht für sinnvoll: Eine Funktion mit Komplexität 20 ist nicht unbedingt sauberer als eine Funktion mit Komplexität 30. Es lohnt sich jedoch, Metriken auszuführen, um nach großen Unterschieden zu suchen.

Einmal habe ich ein paar Dutzend Projekte untersucht und eines der Projekte hatte einen maximalen Komplexitätswert von etwa 6.000, während jedes andere Projekt einen Wert von 100 oder weniger hatte. Das traf mich über den Kopf wie ein Baseballschläger. Offensichtlich war mit diesem Projekt etwas Ungewöhnliches und wahrscheinlich Schlechtes los.

Wir sind Programmierer. Wir mögen Zahlen.

Was werden Sie tun, NICHT die Größe der Codebasis beschreiben, da "Zeilen mit Codemetriken irrelevant sind"?

Es gibt definitiv einen Unterschied zwischen einer Codebasis von 150 Zeilen und einer von 150 Millionen, um ein dummes Beispiel zu nennen. Und es ist nicht schwer, eine Nummer zu bekommen.