Was sind nützliche Metriken für den Quellcode? [geschlossen]

Welche nützlichen Metriken können für den Quellcode erfasst werden?

Wie können Metriken wie zum Beispiel (Executable?) Codezeilen oder zyklomatische Komplexität bei der Qualitätssicherung helfen oder wie sind sie allgemein für den Softwareentwicklungsprozess von Nutzen?

"Das Messen der Softwareproduktivität anhand von Codezeilen ist wie das Messen des Fortschritts in einem Flugzeug anhand seines Gewichts." - Bill Gates

Werfen Sie einen Blick auf Jeffs Beiträge zum Thema:

Ein Besuch von der Metrics Maid

Software Engineering: Tot?

Es gibt auch einen alten, aber guten Post von Joel, der eng mit Software-Metriken verwandt ist, und ich empfehle dringend, ihn zu lesen: Die Econ 101-Verwaltungsmethode

Für mich ist dies der entscheidende Punkt, indem ich Jeff zitiere: "Der verantwortungsbewusste Umgang mit den Metriken ist genauso wichtig wie deren Erfassung an erster Stelle."

Was mich an Codemetriken verwirrt, ist, dass es nicht mehr gemacht wird. Die meisten Unternehmen berichten über die Effizienz ihrer Mitarbeiter, Lieferanten und Systeme, aber niemand scheint über Code berichten zu wollen. Ich werde definitiv Antworten zustimmen, die besagen, dass mehr Codezeilen eine Haftung darstellen, aber was Ihr Code tut, ist wichtiger.

Codezeilen: Wie ich bereits erwähnt habe, ist dies eine wichtige Messung und sollte am ernstesten genommen werden, jedoch auf jeder Ebene. Funktionen, Klassen, Dateien und Schnittstellen können auf Code hinweisen, der auf lange Sicht schwer zu warten und kostspielig ist. Es ist unendlich schwer, die gesamten Codezeilen mit der Leistung eines Systems zu vergleichen. Es könnte etwas sein, das viele Dinge tut und in diesem Fall wird es viele Codezeilen geben!

Komplexität: Diese Messung eignet sich gut für Codebasen, an denen Sie noch nicht gearbeitet haben, und kann Ihnen einen guten Hinweis darauf geben, wo Problembereiche liegen. Als nützliche Anekdote habe ich die Komplexität anhand einer meiner eigenen Codebasen gemessen, und der Bereich mit der höchsten Komplexität war derjenige, den ich am meisten verbrachte, als ich ihn ändern musste. Die Reduzierung der Komplexität führte zu einer massiven Reduzierung der Wartungszeit. Wenn das Management diese Messungen zur Hand hätte, könnten sie Refactoring-Iterationen oder Redesigns bestimmter Bereiche eines Systems planen.

Code-Vervielfältigung: Dies ist für mich eine sehr wichtige Messung. Die Vervielfältigung von Code ist ein sehr schlechtes Zeichen und kann entweder auf schwerwiegende Probleme in niedrigen Ebenen des Systemdesigns oder auf Entwickler hinweisen, die Copy-Paste betreiben, was auf lange Sicht massive Probleme verursacht, und auf Systeme, die nicht instand gehalten werden können.

Abhängigkeitsdiagramme Das Auffinden fehlerhafter Abhängigkeiten und zirkulärer Abhängigkeiten ist ein wichtiges Maß im Code. Dies deutet fast immer auf ein falsches High-Level-Design hin, das überarbeitet werden muss. Manchmal kann eine Abhängigkeit eine Menge unnötiger anderer Abhängigkeiten in Anspruch nehmen, da jemand die addNumber in einer E-Mail-Bibliothek verwendet, um seine Finanzberechnungen durchzuführen. Jeder ist schockiert, wenn die E-Mail-Bibliothek geändert wird und die Finanzen zusammenbrechen. Wenn alles von einer Sache abhängt, kann es auch darauf hindeuten, alles zu tun, was Bibliotheken schwer zu pflegen und schlecht gestaltet sind.

Eine gute Messung zeigt Ihnen immer, dass jedes Merkmal eines Systems einen geringen Platzbedarf hat. Weniger Abhängigkeiten, weniger Komplexität, weniger Doppelarbeit. Dies deutet auf lose Kopplung und hohe Kohäsion hin.

Wird diese "Quellcode-Metrik" nicht JEDEN sterben?

Raw Source Code Lines of Code (SLOC) ist die älteste, einfachste und grundlegendste Metrik, die es gibt.

Halstead schlug ursprünglich eine ganze Reihe von Metriken vor. Viele Leute hatten viel Spaß beim Schreiben von Messprogrammen, bis ein Teil der Spielverderber die offensichtliche Studie durchführte und zeigte, dass jede einzelne Halstead-Metrik stark direkt mit dem SLOC korrelierte.

Zu diesem Zeitpunkt wurden die Metriken von Halstead aufgegeben, da der SLOC immer einfacher zu messen ist.

Quellcodemetriken zur Qualitätssicherung verfolgen zwei Ziele:

• Schreiben von Code mit weniger Fehlern
• Schreiben von Code für eine einfache Wartung

Beides führt dazu, dass Code so einfach wie möglich geschrieben wird. Das heisst:

• kurze Codeeinheiten (Funktionen, Methoden)
• wenige Elemente in jeder Einheit (Argumente, lokale Variablen, Anweisungen, Pfade)
• und viele andere Kriterien mehr oder weniger komplex (siehe Software-Metrik in Wikipedia).

Nach meinem besten Wissen korreliert die Anzahl der gefundenen Fehler direkt mit Codezeilen (wahrscheinlich Abwanderung), Modulo-Sprache, Programmierer und Domäne.

Ich kenne keine andere einfache und praktische Metrik, die gut mit Fehlern korreliert.

Eine Sache, die ich tun möchte, ist, die Zahlen für verschiedene Projekte, an denen ich arbeite, zu erfassen - Test Coverage :: kLOC - und dann über "wahrgenommene Qualität" zu diskutieren, um festzustellen, ob es eine Korrelation gibt.

Metriken sind nur dann nützlich, wenn Sie wissen, wie Sie mit den erhaltenen Antworten umgehen sollen. Im Wesentlichen ist eine Softwaremetrik wie ein Thermometer. Die Tatsache, dass Sie etwas bei 98,6 ° F messen, hat erst dann eine Bedeutung, wenn Sie die normale Temperatur kennen. Die obige Temperatur ist gut für die Körpertemperatur, aber sehr schlecht für Eis.

Gängige Metriken, die nützlich sein können , sind:

• Fehler entdeckt / Woche
• Bugs behoben / Woche
• # Anforderungen definiert / freigeben
• # Anforderungen implementiert / freigegeben

Die ersten beiden messen Trends. Finden Sie Fehler schneller als Sie sie beheben können? Zwei mögliche Ergebnisse: Vielleicht brauchen wir mehr Ressourcen, um Fehler zu beheben, vielleicht müssen wir die Implementierung neuer Funktionen einstellen, bis wir aufholen. Die zweiten beiden zeigen, wie nah Sie dran sind. Agile Teams nennen es ein "Burn Down" -Diagramm.

Die zyklomatische Komplexität ist eine interessante Metrik. Das Grundkonzept ist die Anzahl der eindeutigen Ausführungspfade in einer Funktion / Methode. In einer Umgebung mit vielen Komponententests entspricht dies der Anzahl der Tests, die zum Überprüfen jedes Ausführungspfads erforderlich sind. Nur weil Sie eine Methode mit einer zyklomatischen Komplexität von 96 haben, heißt das nicht, dass es sich um fehlerhaften Code handelt - oder dass Sie 96 Tests schreiben müssen, um ein angemessenes Vertrauen zu schaffen. Es ist nicht ungewöhnlich, dass generierter Code (über WPF- oder Parser-Generatoren) etwas so Komplexes erstellt. Es kann eine ungefähre Vorstellung vom Umfang des zum Debuggen einer Methode erforderlichen Aufwands geben.

Endeffekt

Für jede Messung muss Folgendes definiert sein, sonst ist sie unbrauchbar:

• Verstehen, was "normal" ist. Dies kann über die Laufzeit des Projekts angepasst werden.
• Eine Schwelle außerhalb von "normal", bei der Sie Maßnahmen ergreifen müssen.
• Ein Plan für den Umgang mit dem Code, wenn der Schwellenwert überschritten wird.

Die von Ihnen verwendeten Metriken können von Projekt zu Projekt sehr unterschiedlich sein. Möglicherweise haben Sie einige Metriken, die Sie projektübergreifend verwenden, aber die Definition von "normal" unterscheidet sich. Wenn ein Projekt beispielsweise durchschnittlich 5 Bugs / Woche entdeckt und das neue Projekt 10 Bugs / Woche entdeckt, bedeutet dies nicht unbedingt, dass etwas nicht stimmt. Vielleicht ist das Testteam diesmal akribischer. Außerdem kann sich die Definition von "normal" während der Laufzeit des Projekts ändern.

Die Metrik ist nur ein Thermometer, was Sie damit machen, liegt bei Ihnen.

Der Quellcode ist eine Verbindlichkeit, kein Vermögenswert. In diesem Sinne entspricht das Messen von Codezeilen dem Nachverfolgen von Dollars, die beim Bauen eines Hauses ausgegeben wurden. Es muss getan werden, wenn Sie unter dem Budget bleiben möchten, aber Sie würden nicht unbedingt denken, dass es besser ist, 1000 USD pro Tag auszugeben, als 50 USD pro Tag. Sie möchten wissen, wie viel des Hauses für dieses Geld gebaut wurde. Das Gleiche gilt für Codezeilen in einem Softwareprojekt.

Kurz gesagt, es gibt keine nützlichen Metriken für den Quellcode, da es nicht sinnvoll ist, den Quellcode selbst zu messen.

Da der Quellcode einfach eine Kombination aus Sequenz, Auswahl und Wiederholung ist. Wenn ich das optimalste Stück Software beschreiben würde, das wir vernünftigerweise jemals produzieren könnten, wäre dies wie folgt. Software mit nahezu 100% iger Code-Testabdeckung mit der geringsten Menge an Codezeilen, die für die Ausführung des Auftrags erforderlich ist, und dennoch flexibel genug, um Änderungen standzuhalten.

Eine Anekdote, die zeigt, warum KLOC-Zählungen für die Leistungsmessung nutzlos (und sogar schädlich) sind.

Vor Jahren arbeitete ich an einem großen Projekt (über 70 Mitarbeiter in unserem Unternehmen, weitere über 30 Mitarbeiter bei unserem Kunden), bei dem KLOC als einziges Maß für die Leistung von Teams und Einzelpersonen herangezogen wurde.

Für unsere Y2K-Bemühungen (sagt Ihnen, wie lange es her ist :)) haben wir einen großen Teil des Codes aufgeräumt, für den mein Team verantwortlich war. Wir haben für die Veröffentlichung ungefähr 30.000 Codezeilen geschrieben, keine schlechten 3 Monate Arbeit für 5 Leute. Am Ende haben wir außerdem weitere 70.000 Codezeilen verschrottet, ein sehr guter Job für 3 Monate Arbeit, insbesondere in Kombination mit dem neuen Code.

Endergebnis für das Quartal: -40.000 Codezeilen. Während der Leistungsüberprüfung nach dem Quartal erhielten wir einen offiziellen Verweis vom Unternehmen, weil wir unsere Produktivitätsanforderungen von 20.000 pro Quartal produzierten Codezeilen nicht erfüllt hatten (die Tools hatten immerhin gezeigt, dass wir -40.000 Codezeilen produziert hatten) hätte dazu geführt, dass wir alle als unterdurchschnittlich eingestuft und für Beförderungen, Schulungen, Gehaltserhöhungen usw. umgangen worden wären. Hätten nicht der Projektmanager und das QA-Team eingegriffen und den Verweis aufgehoben und durch eine Belobigung ersetzt.

Ein paar Monate später (solche Dinge brauchen Zeit) wurde uns mitgeteilt, dass das Unternehmen ihre Produktivitätsstandards überprüfe und ein Expertenteam damit beauftragt habe, ein neues System auf Basis der Funktionspunktanalyse zu entwickeln.

Ich bin überrascht, dass noch niemand die Aussage / Entscheidung über Unit-Tests (Prozentsatz des Codes, der von Unit-Tests ausgeübt wird) erwähnt hat.

Die Codeabdeckung ist hilfreich, wenn Sie wissen, welcher Prozentsatz der Anwendung nicht katastrophal ausfällt. Der Rest des Nutzens hängt von der Qualität der Unit-Tests ab.

Je kleiner der Commit, desto besser. Hier geht es um SCM-Tools, nicht um Code an sich, aber es ist eine sehr messbare Metrik. Je kleiner das Commit, desto einfacher ist es, jede Änderung als atomare Einheit zu sehen. Je einfacher es ist, bestimmte Änderungen rückgängig zu machen und genau zu bestimmen, wann etwas kaputt gegangen ist.

Solange kein Commit den Build unterbricht ...

Dies sind keine sehr nützlichen absoluten Metriken für den Fortschritt, können aber verwendet werden, um eine allgemeine Vorstellung vom Status des Codes zu vermitteln.

Insbesondere die zyklomatische Komplexität hat sich als nützlich erwiesen, um zu visualisieren, wie modular eine bestimmte Codebasis ist. Sie möchten im Allgemeinen eine geringe Komplexität, da dies bedeutet, dass die Anzahl der Quellen pro Modul gering ist und es viele Module gibt.

Ich arbeite oft an einem riesigen C ++ - Paket, und wenn ich nach problematischem Code suche, der es wert ist, die zyklomatische Komplexität umzugestalten , oder wenn schreckliche FanIn / FanOut-Funktionen verwendet werden, ist das normalerweise eine ziemlich gute rote Flagge. Das Beheben von Problemen führt normalerweise zu Verbesserungen in der gesamten Codebasis.

Natürlich können diese Zahlen nur als Anhaltspunkt dafür dienen, was es wert wäre, betrachtet zu werden. Es wäre lächerlich, wenn dies eine schwierige Schwelle wäre, nach der ein Build fehlschlägt oder ein Commit verweigert wird.

Es gibt viele Situationen bei meiner Arbeit, in denen ich Codemetriken verwende:

Beim Schreiben von Code

Die größte und vielleicht wichtigste Verwendung in meiner täglichen Arbeit ist Checkstyle , ein Tool für Java-Entwickler, das die Metriken (unter anderem) meines Codes kontinuierlich anhand eines von uns definierten Regelwerks überprüft und Stellen markiert, an denen mein Code nicht funktioniert diese Regeln einhalten. Während ich Code entwickle, erfahre ich in Echtzeit, ob meine Methoden zu lang, zu komplex oder zu gekoppelt sind, sodass ich einen Schritt zurücktreten und darüber nachdenken kann, sie zu etwas Besserem umzugestalten.

Es steht Entwicklern völlig frei, alle Regeln zu brechen, da sie niemals für alle Situationen gelten. Die "Regeln" regen zum Nachdenken an und sagen: "Hey, ist das der beste Weg, dies zu tun?"

Während der QA / Code-Überprüfungen

Wenn ich eine Codeüberprüfung durchführe, überprüfe ich in der Regel zuerst die Codeabdeckung des Codes, den ich überprüfe, in Verbindung mit einem Tool zur Codeabdeckung, mit dem hervorgehoben wird, welche Codezeilen abgedeckt wurden. Dies gibt mir eine allgemeine Vorstellung davon, wie gründlich der Testcode ist. Es ist mir eigentlich egal, ob die Abdeckung 20% ​​oder 100% beträgt, solange der wichtige Code gut getestet ist. So ist der Prozentsatz, der abgedeckt wird, etwas bedeutungslos, aber 0% heben sich wie ein schmerzender Daumen als etwas hervor, das ich sorgfältig betrachten möchte.

Ich überprüfe auch, ob die vom Team vereinbarten Messwerte "gebrochen" wurden, um festzustellen, ob ich mit dem Entwickler einverstanden bin, dass dies in Ordnung ist, oder ob ich Verbesserungsvorschläge machen kann. Die Vereinbarung dieser Entwicklungsmetriken in unserem Team zum Schreiben von neuem Code hat die Verbesserung unseres Codes erheblich beschleunigt. Wir schreiben viel weniger monolithische Methoden und beherrschen das Prinzip der Einzelverantwortung jetzt viel besser .

Trending Verbesserungen an Legacy-Code Wir haben eine Menge Legacy-Code, den wir verbessern möchten . Die Metriken zu jedem Zeitpunkt sind ziemlich nutzlos, aber was uns wichtig ist, ist, dass die Codeabdeckung mit der Zeit steigt und Dinge wie Komplexität und Kopplung sinken. Aus diesem Grund sind unsere Metriken in unseren Continuous Integration-Server integriert, sodass wir im Laufe der Zeit nachsehen können, ob wir auf dem richtigen Weg sind.

Neue Codebasis in den Griff bekommen Das einzige Mal, dass ich Quellcodemetrikzeilen verwende, ist die Betrachtung einer Codebasis, mit der ich nicht vertraut bin. Dadurch kann ich die ungefähre Größe des Projekts im Vergleich zu anderen Projekten, mit denen ich gearbeitet habe, schnell abschätzen. Mit anderen Metriken kann ich mir auch einen groben Überblick über die Qualität des Projekts verschaffen.

Die wichtigsten Dinge sind, Metriken als Ausgangspunkte für Trends, Diskussionen oder Wege in die Zukunft zu verwenden und sie nicht religiös zu verwalten, um genaue Zahlen zu erhalten. Aber ich bin der festen Überzeugung, dass sie Ihnen helfen können, den Code zu verbessern, den Sie richtig verwenden.

F: Welche nützlichen Metriken können für den Quellcode erfasst werden?

Für das Geschäft:

A: Anzahl der Mannstunden

Für den Supervisor des Programmierers:

A: Egal. Lass uns heute alles machen

Für das Selbstwertgefühl des Programmierers:

A: Anzahl der SLOC (Source Lines of Code)

Für die Mutter des Programmierers:

A: Iss mehr von diesen weichen französischen Brötchen und trinke Tee

Fortsetzung in Kommentaren unten ...

Denken Sie daran: Der gesamte Code kann um mindestens eine Anweisung reduziert werden. Der gesamte Code enthält mindestens 1 Fehler. Daher kann der gesamte Code auf einen einzigen Befehl reduziert werden, der nicht funktioniert. Hoffentlich hilft das!