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

33

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?

cschol
quelle
37
Das einzig gültige Maß ist WTF / Sek. :)
Terminus
2
@terminus osnews.com/story/19266/WTFs_m :-)
thbusch

Antworten:

30

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

Chrisaycock
quelle
3
Bitte aktualisieren Sie keine nicht beantworteten Fragen.
Eric Wilson
3
Obwohl diese Antwort eine amüsante Anekdote ist, trägt sie wenig zur Beantwortung dieser Frage bei.
Chris Knight
7
@Chris Diese Antwort erhielt viele positive Stimmen (oder "Updates", wie FarmBoy sie nennen möchte), weil viele Entwickler glauben, dass Softwaremetriken nutzlos sind. Wenn Sie anderer Meinung sind oder der Meinung sind, dass Sie eine bessere Antwort auf die Frage haben, veröffentlichen Sie Ihre eigene Antwort. Das Kommentieren, wie Sie es hier getan haben, ist nicht produktiv. Sie haben selbst nichts beigetragen.
Chrisaycock
7
Meine Ablehnung und mein Kommentar sollen Antworten entmutigen, denen es an Tiefe mangelt und die sich nicht direkt mit der Frage des OP befassen. Dies könnte eine viel bessere Antwort sein, wenn Sie näher darauf eingehen, warum Sie glauben, dass Softwaremetriken in Bezug auf Softwareentwicklung und Qualitätssicherung nutzlos sind und sich auf mehr als nur LOC konzentrieren.
Chris Knight
Softwaremetriken sind sehr nützlich, wenn Sie sie richtig verwenden. Das heißt, je mehr LoC -> je mehr Bugs -> desto schlechter die Qualität. Ich habe noch nie gesehen, dass dies als Maß für die Qualität misslingt. Und ein Flugzeug ist definitiv besser, wenn es dieselbe Reise mit derselben Geschwindigkeit durchführt, aber viel weniger Gewicht benötigt. Offensichtlich wusste Bill Gates weder viel über Flugzeuge, als er das sagte, noch genug über Software, wie es scheint.
Pablo Ariel
12

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."

Machado
quelle
+1 für das Zitieren von Jeffs Einzeiler. Reine, kampferprobte Weisheit.
Luis.espinal
11

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.

Tjaart
quelle
8

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.

John R. Strohm
quelle
1
Irgendwelche Links zur Studie?
Jon Hopkins
Google ist dein Freund, aber hier ist einer, der dir den Einstieg erleichtert. ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
John R. Strohm
6
Interessante Studie, obwohl sich ihre Studie nur mit Programmen im Allgemeinen zwischen 50 und 100 Codezeilen befasste. Mit einem so kleinen, genau definierten Problem scheint das Endergebnis nicht so überraschend zu sein.
Chris Knight
Ich würde sagen, dass sich all diese Studien in der realen Welt in Schlamm verwandeln.
Warren P
Das ist wahr. Je mehr Codezeilen vorhanden sind, desto besser ist die Qualität.
Pablo Ariel
8

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).
mouviciel
quelle
7

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.

Paul Nathan
quelle
1
Je mehr Code es gibt, desto mehr Bugs gibt es?
3
@Thor: Ja, ja. Schocker, nicht wahr?
Paul Nathan
Soweit ich mich erinnere, belaufen sich die typischen Branchenzahlen bei durchschnittlichen Projekten auf etwa 2-3 Fehler pro 1000 Codezeilen. Bei Software für die Steuerung von Kernkraftwerken oder NASA-Projekten, bei denen enorme Anstrengungen unternommen wurden, nähern sie sich etwa 0,5 Fehlern pro 1000 Codezeilen , Kontrolle, Prüfung, Überprüfung usw., da Ausfälle sehr schwerwiegende Folgen haben können. Hat jemand einen Hinweis auf Zahlen, die dies unterstützen?
hlovdal
2
@hlovdal: 2-3 Fehler pro KSLOC sind schon ein sehr niedriger Wert. Die niedrigsten Werte, die ich aus der Luftfahrt- und Sicherheitsbranche kenne, liegen in der Größenordnung von 0,1 Fehlern pro KSLOC. Typische Werte scheinen 20 bis 50 Fehler pro KSLOC zu sein. Als Referenz dient der Artikel von Google für Andy German mit dem Titel "Software Static Code Analysis - Lessons Learned".
Schedler
1
Ich würde diese Zahlen bestreiten - es hängt ganz von der Sprache, dem Compiler und der ausführbaren Umgebung ab. Typos in JavaScript - Code kann dauern Jahre zu finden, aber ein Tippfehler in einer kompilierten Sprache würde auf der ersten Kompilierung gefunden werden.
JBRWilkinson
7

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.

Berin Loritsch
quelle
Ein weiterer Fehler, der in einigen Fällen nützlich sein kann, sind Fehler pro Codezeile. Im Allgemeinen sollten ausgereifte Codebasen eine relativ geringe Anzahl von Fehlern pro Codezeile aufweisen, im Gegensatz zu Anwendungen, die sich noch in der Entwicklung befinden.
rjzii
@Rob Z, mit jeder Metrik werden die Leute gerade genug tun, um diese Metrik zu optimieren. Bei Fehlern pro Codezeile kann es vorkommen, dass ein Entwickler eine nicht verwendete Variable einführt, die erhöht wird, um die Anzahl der fehlerfreien LOCs zu erhöhen (da SLOC-Leistungsindikatoren mehrere Semikolons erkennen können). Dies erhöht natürlich auch künstlich die Menge an Code, die durchlaufen werden muss.
Berin Loritsch
6

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.

Larry Coleman
quelle
4

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.

Xenohacker
quelle
2
Eine Abdeckung von 100% ist nur dann 100%, wenn alle Pfade und nicht nur alle Linien abgedeckt sind. In jeder realistischen Software ist eine 100% ige Pfadabdeckung ein schlechtes Ziel, da die Erreichung dieses Ziels sehr teuer ist und Ihnen nur sagt, dass sich Ihr Code wie geplant verhält, nicht, dass das Design selbst einwandfrei ist. Sie könnten Sicherheitslücken und eine 100% ige Pfadabdeckung haben.
Joeri Sebrechts
+1 Mehr Quellcode ist nicht unbedingt besser.
Larry Coleman
Nur sehr einfache Anwendungen können zu 100% getestet werden (wodurch die Abdeckung überflüssig wird). Es ist rechenintensiv (wenn nicht unmöglich), eine 100% ige Testabdeckung für komplexe Software zu erreichen. Wir kennen diese Tatsache seit ungefähr 6 Jahrzehnten. Zweitens zeigt das Testen nur, dass Sie keinen Fehler gefunden haben - es garantiert nicht, dass es keine Fehler gibt, die sich nicht auf die strukturelle Qualität, Größe oder Komplexität beziehen (etwas, das auch schon seit langer Zeit bekannt ist) In der Software ist es vergleichbar mit einem Physiker, der die Gesetze der Thermodynamik nicht wirklich kennt.
Luis.espinal
@ luis.espinal Software, die so groß ist, dass sie zu rechenintensiv zum Testen ist, ist unglaublich schlecht geschriebene Software. Es ist nahe daran, keine Ahnung zu haben, wie man funktionierende Software herstellt.
Pablo Ariel
@PabloAriel - „Software so groß , dass auch rechnerisch teuer zu Test ist“ << Das ist nicht , was ich sagte. Lesen Sie den Kommentar (möglicherweise zwei- oder dreimal), um sicherzustellen, dass Sie tatsächlich lesen, was Sie zu lesen glauben.
Luis.espinal
4

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.

jwenting
quelle
Warum hast du nicht nur die Unterschiede gezeigt ?!
Reinierpost
Ich denke, das wurde gemacht. Aber wenn ein System so starr ist, läutet es nicht einmal Alarmglocken, wenn ein solch offensichtlich falscher Datenpunkt erscheint, dass es nicht viel bringt.
28.
2
Ihre Antwort zeigt nicht, dass KLOC nutzlos sind, sondern wie Sie sie nicht verwenden können.
Neil N
2
es zeigt, dass es kurzsichtig ist, sich auf sie als Maß für die Produktivität zu verlassen, und sich auf sie zu verlassen, da die einzige Maßnahme idiotisch ist. In anderen Projekten, in denen KLOC als Maß für Produktivität und sogar Qualität verwendet wird, haben wir die Zahlen leicht aufgeblasen, indem wir Codierungsstandards erstellt haben, die viele Zeilen verursachten (C ++ - Klammerungspraktiken, zusätzliche leere Zeilen mit nur einem kurzen Kommentar überall, die die Bedingungen in einer if-Anweisung aufteilen) 3 Zeilen usw.).
21.
1
Die Verwendung von SLOC als Produktivitätsmetrik ist einfach doof und wird wahrscheinlich nie gute Ergebnisse liefern. Die Verwendung von SLOC als Qualitätsmaßstab für die Wartbarkeit und die Anzahl der Fehler ist vernünftiger, da alle Vorbehalte zu dieser Frage bereits besprochen wurden.
Redcalx
2

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.

StuperUser
quelle
Code-Coverage ist ebenfalls eine falsche Metrik (obwohl sie eine gewisse Verwendung haben kann). Es lädt zum Schreiben von Unsinnstests ein, nur um eine höhere Abdeckung zu erhalten. Und natürlich gibt es Dinge, die niemals verdeckt werden, und die Leute werden anfangen, solche Dinge nicht zu schreiben. ZB habe ich Tools zur Codeabdeckung gesehen, die JavaDoc als Code gekennzeichnet haben und die natürlich nicht behandelt werden. Ein anderes Tool markierte alle leeren Zeilen als nicht von Tests abgedeckt. Sie wären damit einverstanden, dass das Wegfallen von Kommentaren und Leerzeichen in Ihrem Code schlimmer ist, als dass bei einigen Setzern, wie ich hoffe, Unit-Tests versäumt werden?
28.
Absolut, schlechte Unit-Tests schaden in vielerlei Hinsicht mehr als sie helfen. Beispielsweise könnten Sie eine 100% ige Codeabdeckung für eine Reihe von Tests erhalten, für die es keine einzelne Zusicherung gab.
StuperUser
1

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 ...

Assaf Lavie
quelle
1

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.

user1249
quelle
1

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.

Benjamin Bannier
quelle
1

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.

Chris Knight
quelle
0

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 ...

Genius
quelle
-1

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!

Will Kunkel
quelle
und mit weniger Nebenwirkungen.
Oder kann es: en.wikipedia.org/wiki/Sorites_paradox
StuperUser