it-swarm-eu.dev

Was sind nützliche Metriken für den Quellcode?

Welche nützlichen Metriken sind für den Quellcode zu erfassen?

Wie können Metriken wie beispielsweise (ausführbare?) Codezeilen oder zyklomatische Komplexität bei der Qualitätssicherung helfen oder wie sind sie im Allgemeinen für den Softwareentwicklungsprozess von Vorteil?

33
cschol

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

30
chrisaycock

Werfen Sie einen Blick auf Jeffs Beiträge zu diesem Thema:

Ein Besuch von der Metrics Maid

Software Engineering: Tot?

Es gibt auch einen alten, aber guten Beitrag von Joel, der eng mit Softwaremetriken zusammenhängt, und ich empfehle dringend, ihn zu lesen: The Econ 101 Management Method

Der entscheidende Punkt für mich ist dies, indem ich Jeff zitiere: "Der verantwortungsvolle Umgang mit den Metriken ist genauso wichtig wie deren Erfassung."

12
Machado

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

Zeilen des Codes : Wie ich bereits erwähnt habe, ist dies eine wichtige Messung und sollte am ernstesten genommen werden, aber auf jeder Ebene. Funktionen, Klassen, Dateien und Schnittstellen können auf Do-Everything-Code hinweisen, der auf lange Sicht schwer zu warten und kostspielig ist. Es ist unendlich schwierig, die gesamten Codezeilen mit denen 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 auf einer meiner eigenen Codebasen gemessen, und der Bereich mit der höchsten Komplexität war derjenige, den ich am meisten Zeit verbrachte, als ich ihn ändern musste. Die Reduzierung der Komplexität führte zu einer massiven Verkürzung der Wartungszeit. Wenn das Management diese Messungen zur Hand hätte, könnte es Refactoring-Iterationen oder Neugestaltungen bestimmter Bereiche eines Systems planen.

Codeduplizierung : Dies ist für mich eine sehr wichtige Messung. Das Duplizieren von Code ist ein sehr schlechtes Zeichen und kann entweder auf tiefgreifende Probleme in niedrigen Ebenen des Systemdesigns oder auf Entwickler hinweisen, die Kopien einfügen, was langfristig zu massiven Problemen führt und Systeme, die nicht gewartet werden können.

Abhängigkeitsgraphen Das Auffinden von schlechten Abhängigkeiten und zirkulären Abhängigkeiten ist eine wichtige Messung 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 absorbieren, weil jemand 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 unterbrochen werden. Wenn alles von einer Sache abhängt, kann es auch auf Do-Everything-Bibliotheken hinweisen, die schwer zu warten 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 eine lose Kopplung und einen hohen Zusammenhalt hin.

11
Tjaart

Wird dieser "Quellcode-Metrik" -Dreck NIEMALS sterben?

Raw Source Codezeilen (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 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 SLOC immer einfacher zu messen ist.

8
John R. Strohm

Quellcode-Metriken zur Qualitätssicherung zielen auf zwei Ziele ab:

  • 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 mehr oder weniger komplexe Kriterien (siehe Software-Metrik in Wikipedia).
8
mouviciel

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 gerne tun würde, ist, die Zahlen für verschiedene Projekte, an denen ich arbeite, auszuführen - Test Coverage :: kLOC - und dann "wahrgenommene Qualität" zu diskutieren, um festzustellen, ob es eine Korrelation gibt.

7
Paul Nathan

Metriken sind nur dann nützlich, wenn Sie wissen, wie Sie mit den Antworten umgehen sollen. Im Wesentlichen ist eine Software-Metrik wie ein Thermometer. Die Tatsache, dass Sie etwas bei 98,6 ° F messen, bedeutet nichts, bis Sie wissen, wie hoch die normale Temperatur ist. Die obige Temperatur ist gut für die Körpertemperatur, aber sehr schlecht für Eis.

Übliche Metriken, die nützlich sein können, sind:

  • Bugs entdeckt/Woche
  • Fehler behoben/Woche
  • # Anforderungen definiert/Release
  • # Anforderungen implementiert/Release

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 am Ende sind. Agile Teams nennen es ein "Burn-Down" -Diagramm.

Die zyklomatische Komplexität ist eine interessante Metrik. Im Grundkonzept ist es die Anzahl der eindeutigen Ausführungspfade in einer Funktion/Methode. In einer Unit-Test-Umgebung 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, bedeutet dies nicht, dass es sich notwendigerweise um fehlerhaften Code handelt - oder dass Sie 96 Tests schreiben müssen, um ein angemessenes Vertrauen zu gewährleisten. Es ist nicht ungewöhnlich, dass generierter Code (über WPF- oder Parser-Generatoren) etwas so Komplexes erstellt. Es kann eine ungefähre Vorstellung davon geben, wie viel Aufwand zum Debuggen einer Methode erforderlich ist.

Fazit

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

  • Ein Verständnis dafür, 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 stark variieren. Möglicherweise haben Sie einige Metriken, die Sie projektübergreifend verwenden, aber die Definition von "normal" ist anders. Wenn beispielsweise ein Projekt durchschnittlich 5 Fehler pro Woche entdeckt und das neue Projekt 10 Fehler pro Woche entdeckt, bedeutet dies nicht unbedingt, dass etwas nicht stimmt. Es könnte sein, dass das Testteam diesmal akribischer ist. Außerdem kann sich die Definition von "normal" im Laufe der Projektlaufzeit ändern.

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

7
Berin Loritsch

Quellcode ist eine Verbindlichkeit, kein Vermögenswert. In diesem Sinne entspricht das Messen von Codezeilen dem Verfolgen von Dollars, die beim Bau eines Hauses ausgegeben wurden. Es muss getan werden, wenn Sie unter dem Budget bleiben möchten, aber Sie würden nicht unbedingt denken, dass 1000 USD pro Tag besser sind als 50 USD pro Tag. Sie möchten wissen, wie viel von dem Haus für dieses Geld gebaut wurde. Ähnlich verhält es sich mit Codezeilen in einem Softwareprojekt.

Kurz gesagt, es gibt keine nützlichen Metriken für den Quellcode, da das Messen des Quellcodes allein nicht sinnvoll ist.

6
Larry Coleman

Da der Quellcode einfach eine Kombination aus Sequenz, Auswahl und Wiederholung ist. Wenn ich die optimalste Software beschreiben würde, von der wir vernünftigerweise erwarten könnten, dass sie produziert wird, wäre dies wie folgt. Software mit nahezu 100% Testcodeabdeckung unter Verwendung der geringsten Anzahl von Codezeilen, die für die Ausführung des Auftrags erforderlich sind, und dennoch flexibel genug, um Änderungen standzuhalten.

4
Xenohacker

Eine Anekdote, die zeigt, warum KLOC-Zählungen nutzlos (und sogar schädlich) sind, um die Leistung zu messen.

Vor Jahren arbeitete ich an einem großen Projekt (über 70 Mitarbeiter in unserem Unternehmen, weitere über 30 bei unserem Kunden), bei dem KLOC-Zählungen als alleiniges Maß für die Leistung von Teams und Einzelpersonen verwendet wurden.

Für unsere Y2K-Bemühungen (sagt Ihnen, wie lange es her ist :)) haben wir den Abschnitt des Codes, für den mein Team verantwortlich war, gründlich bereinigt. Wir haben für die Veröffentlichung ungefähr 30.000 Codezeilen geschrieben, keine schlechten 3 Monate Arbeit für 5 Personen. Am Ende haben wir 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 vom Unternehmen einen offiziellen Verweis, weil wir unsere Produktivitätsanforderungen von 20.000 pro Quartal produzierten Codezeilen nicht erfüllt hatten (schließlich zeigten die Tools, dass wir -40.000 Codezeilen produziert hatten) hätte dazu geführt, dass wir alle für Beförderungen, Schulungen, Gehaltserhöhungen usw. usw. als unterdurchschnittlich eingestuft und umgangen wurden, wenn der Projektmanager und das QS-Team nicht eingegriffen und den Verweis aufgehoben und durch eine Belobigung ersetzt hätten.

Einige Monate später (solche Dinge brauchen Zeit) wurde uns mitgeteilt, dass das Unternehmen seine Produktivitätsstandards überprüft und ein Expertenteam beauftragt hat, ein neues System auf der Grundlage der Funktionspunktanalyse zu erstellen.

4
jwenting

Ich bin überrascht, dass noch niemand die Aussage/Entscheidungsabdeckung von Unit-Tests (Prozentsatz des von Unit-Tests ausgeübten Codes) erwähnt hat.

Die Codeabdeckung ist nützlich, da Sie wissen, wie viel Prozent der Anwendung nicht katastrophal fehlschlagen. Der Rest seiner Nützlichkeit hängt von der Qualität der Unit-Tests ab.

2
StuperUser

Diese sind nicht sehr nützlich absolut Metriken in Bezug auf den Fortschritt, können aber verwendet werden, um eine allgemeine Vorstellung vom Status des Codes zu geben.

Insbesondere zyklomatische Komplexität Ich habe festgestellt, dass sie nützlich ist, um zu visualisieren, wie modularisiert 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.

1
user1249

Je kleiner die Commits sind, desto besser ist es normalerweise. 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. desto einfacher ist es, bestimmte Änderungen rückgängig zu machen und genau zu bestimmen, wann etwas kaputt gegangen ist.

Solange kein Commit den Build unterbricht ...

1
Assaf Lavie

Bei meiner Arbeit gibt es viele Situationen, in denen ich Codemetriken verwende:

Beim Schreiben von Code

Die größte und vielleicht wichtigste Verwendung in meinem täglichen Job ist Checkstyle , ein Tool für Java Entwickler, das die Metriken (unter anderem) meines Codes kontinuierlich überprüft Eine Reihe von Regeln, die wir definiert haben und die Orte kennzeichnen, an denen mein Code diesen Regeln nicht entspricht. Während ich Code entwickle, wird mir in Echtzeit mitgeteilt, ob meine Methoden zu lang, zu komplex oder zu gekoppelt sind, sodass ich zurücktreten und zurücktreten kann Denken Sie darüber nach, es zu etwas Besserem umzugestalten.

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

Während QA/Code Reviews

Das erste, was ich normalerweise mache, wenn ich eine Codeüberprüfung durchführe, ist die Überprüfung der Codeabdeckung des Codes, den ich überprüfe, in Verbindung mit einem Tool zur Codeabdeckung, das hervorhebt, welche Codezeilen abgedeckt wurden. Dies gibt mir eine allgemeine Vorstellung davon, wie gründlich der Testcode ist. Es ist mir egal, ob die Abdeckung 20% ​​oder 100% beträgt, solange der wichtige Code gut getestet ist. Somit ist der abgedeckte Prozentsatz etwas bedeutungslos, aber 0% fallen sicher wie ein schmerzender Daumen als etwas auf, das ich mir genau ansehen möchte.

Ich überprüfe auch, welche vom Team vereinbarten Metriken gegebenenfalls "gebrochen" wurden, um festzustellen, ob ich dem Entwickler zustimme, dass dies in Ordnung ist, oder ob ich Möglichkeiten zur Verbesserung vorschlagen kann. Die Vereinbarung dieser Entwicklungsmetriken in unserem Team für das Schreiben von neuem Code hat große Fortschritte bei der Verbesserung unseres Codes gemacht. Wir schreiben viel weniger monolithische Methoden und sind jetzt viel besser im Prinzip der Einzelverantwortung .

Trendverbesserungen für Legacy-Code Wir haben eine Menge Legacy-Code, den wir verbessern möchten. Die Metriken sind zu jedem Zeitpunkt ziemlich nutzlos, aber was uns wichtig ist, ist, dass die Codeabdeckung im Laufe der Zeit zunimmt und Dinge wie Komplexität und Kopplung sinken. Daher werden unsere Metriken in unseren Continuous Integration-Server integriert, sodass wir im Laufe der Zeit nachsehen können, ob wir auf dem richtigen Weg sind.

Eine neue Codebasis in den Griff bekommen Das einzige Mal, dass ich jemals Zeilen mit Quellcode-Metrik verwende, ist das Betrachten einer Codebasis, die ich nicht kenne mit. Dadurch kann ich die grobe Größe des Projekts im Vergleich zu anderen, mit denen ich gearbeitet habe, schnell abschätzen. Mit anderen Metriken kann ich mir auch eine weitere grobe Vorstellung von der Qualität des Projekts machen.

Die wichtigsten Dinge sind, Metriken als Ausgangspunkte für Trends, Diskussionen oder Wege nach vorne zu verwenden und sie nicht religiös zu verwalten, um genaue Zahlen zu erhalten. Ich bin jedoch der festen Überzeugung, dass sie Ihnen helfen können, den Code zu verbessern, den Sie bei richtiger Verwendung richtig einsetzen.

1
Chris Knight

Ich arbeite oft an einem riesigen C++ - Paket, und wenn ich nach problematischem Code suche, der es wert ist, überarbeitet zu werden, sind Cyclomatic Complexity oder schreckliche FanIn/FanOut normalerweise ziemlich gute rote Fahnen. Das Beheben von Problemen führt normalerweise zu Verbesserungen in der gesamten Codebasis.

Natürlich können diese Zahlen nur als Hinweis darauf dienen, was einen Blick wert wäre. Es wäre lächerlich, dies zu einer harten Schwelle zu machen, nach der ein Build fehlschlägt oder ein Commit ablehnt.

1

F: Welche nützlichen Metriken sind für den Quellcode zu erfassen?

Für Unternehmen :

A: Anzahl der Arbeitsstunden

Für den Supervisor des Codierers :

A: Egal. Lass uns heute alles machen

Für das Selbstwertgefühl des Codierers :

A: Anzahl der SLOC (Quellcodezeilen)

Für die Mutter des Codierers :

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

Fortsetzung in den Kommentaren unten ...

0
Genius