Objektive Metriken für die Softwarequalität [geschlossen]

12

Es gibt verschiedene Arten von Qualität, die an Softwareprodukten gemessen werden können, z. B. Gebrauchstauglichkeit (z. B. Endverwendung), Wartbarkeit und Effizienz. Einige davon sind subjektiv oder domänenspezifisch (z. B. können sich die Prinzipien für ein gutes GUI-Design in den verschiedenen Kulturen unterscheiden oder vom Verwendungskontext abhängen, denken Sie an die militärische oder die Verbrauchernutzung).

Was mich interessiert, ist eine tiefere Form der Qualität in Bezug auf das Netzwerk (oder den Graphen) der Typen und ihre Wechselbeziehung, dh auf welche Typen bezieht sich jeder Typ? Gibt es klar identifizierbare Cluster von Interkonnektivität in Bezug auf eine ordnungsgemäße mehrstufige Architektur, oder umgekehrt gibt es eine große "Kugel" von Typreferenzen ("monolithischer" Code). Außerdem sollte die Größe jedes Typs und / oder jeder Methode (z. B. gemessen in der Menge des Java-Byte-Codes oder .Net IL) einen Hinweis darauf geben, wo große komplexe Algorithmen als monolithische Codeblöcke implementiert wurden, anstatt in besser verwaltbare / wartbare zerlegt zu werden Stücke.

Eine Analyse, die auf solchen Ideen basiert, kann möglicherweise Metriken berechnen, die mindestens ein Stellvertreter für die Qualität sind. Die genauen Schwellen- / Entscheidungspunkte zwischen hoher und niedriger Qualität sind meines Erachtens subjektiv, da unter Wartbarkeit die Wartbarkeit durch menschliche Programmierer zu verstehen ist und die funktionale Zerlegung daher mit der Funktionsweise des menschlichen Geistes vereinbar sein muss. Als solches frage ich mich, ob es jemals eine mathematisch reine Definition von Softwarequalität geben kann, die alle möglichen Software in allen möglichen Szenarien übersteigt.

Ich frage mich auch, ob dies eine gefährliche Idee ist, dass wenn objektive Proxys für Qualität populär werden, der Geschäftsdruck Entwickler dazu veranlasst, diese Metriken auf Kosten der Gesamtqualität zu verfolgen (jene Aspekte der Qualität, die nicht von den Proxys gemessen werden).

Eine andere Art, über Qualität zu denken, ist unter dem Gesichtspunkt der Entropie. Entropie ist die Tendenz von Systemen, von geordneten zu ungeordneten Zuständen zurückzukehren. Jeder, der jemals an einem realen, mittelgroßen bis großen Softwareprojekt gearbeitet hat, wird es zu schätzen wissen, inwieweit sich die Qualität der Codebasis im Laufe der Zeit verschlechtert. Der Geschäftsdruck führt in der Regel zu Änderungen, die sich auf neue Funktionen konzentrieren (außer wenn Qualität selbst das Hauptverkaufsargument ist, z. B. bei Avionik-Software), und zu Qualitätsverlusten durch Regressionsprobleme und Fehlfunktionen eine Qualitäts- und Wartungsperspektive. Können wir also die Entropie von Software messen? Und wenn ja, wie?

redcalx
quelle
Ich stimme S. Lott zu. Im Leben gibt es häufig einen Unterschied zwischen "wie es sein sollte" und "wie es ist". Junge, ich wünschte, mehr Menschen auf diesem Planeten hätten ihre "guten Absichten" überwunden und sich genau angesehen, wie es ist. Zusätzlich zu falschen Anreizen wird es ein gefährliches falsches Sicherheitsgefühl geben. Kombinieren Sie das mit Leuten, die versuchen, das System zu spielen (was nur natürlich ist, weil sie IMMER versuchen, ihre Bedingungen zu verbessern (ob in Geld oder in anderen)), und Sie bekommen eine beschissene Situation. Es ist nicht verwunderlich, dass Marktabstürze alle zwei Jahrzehnte auftreten.
Job

Antworten:

20

Das ist eine gefährliche Idee. "Objektive" Proxies für Qualität führen direkt zu Belohnungen für das Management, und Entwickler verfolgen diese Metriken auf Kosten der tatsächlichen Qualität.

Dies ist das Gesetz der unbeabsichtigten Konsequenzen.

Qualität ist zwar wichtig, aber nur ein kleiner Aspekt von Software. Funktionalität und Wertschöpfung durch die Software sind weitaus wichtiger als Qualität.

Alle Metriken führen zu Aktivitäten zur Optimierung der Metrik. Dies hat wiederum Konsequenzen, die Sie vielleicht nicht wirklich mögen.

Software ist sehr komplex. Es ist schwer zu verstehen, wie komplex es wirklich ist.

Sogar "offensichtliche" Dinge wie die Codeabdeckung bei Einheitentests können Zeit verschwenden. Um 100% zu erreichen, müssen möglicherweise Tests erstellt werden, die komplexer sind als der zu testende Trivialcode. Das Erreichen einer 100% igen Deckung kann mit inakzeptablen Kosten verbunden sein. [Die Alternative für trivialen, kleinen, selten verwendeten Code ist ein Test durch Inspektion. Aber das passt nicht zum Metrikspiel von 100%.]

Ein weiteres Beispiel ist die zyklomatische Komplexität. Es ist eines der besten Maßstäbe für die Codequalität. Zum Spielen können jedoch viele kleine Funktionen erstellt werden, die möglicherweise schwerer zu lesen (und zu warten) sind als eine größere Funktion. Sie landen in Codeüberprüfungen, in denen Sie zustimmen, dass der Code möglicherweise nicht gut lesbar ist, aber die Komplexitätsschwelle erreicht.

S.Lott
quelle
3
"Alle Metriken führen zu Aktivitäten zur Optimierung der Metrik." Ich denke, das ist zu oft wahr. Es sollte jedoch nicht sein. Metriken sollten, wie ich in meinen letzten Absätzen angedeutet habe, die Verwaltung von Leitfäden. Zu oft werden Entscheidungen jedoch ausschließlich aufgrund und für die Zahlen getroffen, ohne die Bedeutung der Zahlen und die mit der Entscheidung verbundenen Risiken und Kompromisse zu verstehen.
Thomas Owens
3
"Sollte es aber nicht sein." Erklären Sie, auf welche Weise die Leute angewiesen werden können, ihre Belohnungen nicht zu optimieren. Finden Sie ein einziges Beispiel für menschliches Verhalten, bei dem kulturelle Belohnungen (basierend auf allen Arten von verrückten sozialen Strukturen) nicht primär und vorrangig sind und das wichtigste, was die Menschen verfolgen werden. Alles, was "sollte" oder "sollte nicht" beinhaltet, muss daran gemessen werden, was die Leute wirklich tun. Sie optimieren wirklich ihre Belohnungen. Wenn Metriken Teil der Belohnungen sind, optimieren die Mitarbeiter die Metriken. Bitte verwenden Sie nicht "Sollte", um das Verhalten von Personen zu beschreiben.
S.Lott
2
@Thomas Owens: "Sie haben einfach keine Belohnungen, um basierend auf Metriken zu optimieren." Das ist lustig. Wie willst du sie so geheim halten? Sobald ich herausfinde, dass Ihr Code früher als ich akzeptiert wurde, möchte ich wissen, wie das Management entschieden hat, dass Ihr Modul fertig ist und meins nicht. Sobald ich die Metrik gefunden habe, die diese Entscheidung "lenkt", spiele ich die Metriken so schnell wie möglich durch. Wenn es keine Metrik gibt, die ich spielen kann, dann sehe ich, dass die Entscheidung willkürlich war. Das Management mag Sie besser als mich und ich werde aufhören, weil es keinen Leistungsstandard gibt, den ich wahrnehmen kann.
S.Lott
2
@ Thomas Owens: "Ich habe noch nie gesehen, dass Metriken zu Belohnungen führen". Kulturelle Anreize bestehen in allen Situationen, in denen zwei oder mehr Personen zusammenarbeiten. "Individuen werden für ihre Leistung anerkannt". Eine Metrik für die zyklomatische Komplexität wird zum Ziel. Wenn Sie Ihr Ziel der zyklomatischen Komplexität schneller als ich erreichen, gibt es kulturelle Belohnungen: Sie sind "produktiver" als ich. Ich muss meine Komplexitätsmetrik spielen, um so "produktiv" zu sein wie Sie.
S.Lott
2
@ Thomas Owens: "Es ist eine Frage des persönlichen Stolzes". Das ist ein großartiges Beispiel für ein kulturelles Belohnungssystem. Metriken können dies aufgrund der unbeabsichtigten Konsequenzen verzerren, die sich daraus ergeben, dass eine gut aussehende Metrik erstellt wird, die nicht mit gutem Code übereinstimmt. Sie haben ein hervorragendes Beispiel für kulturelle Belohnungen geliefert, die durch Metriken verzerrt werden können.
S.Lott
4

Ich frage mich auch, ob dies eine gefährliche Idee ist, dass wenn objektive Proxys für Qualität populär werden, der Geschäftsdruck Entwickler dazu veranlasst, diese Metriken auf Kosten der Gesamtqualität zu verfolgen (jene Aspekte der Qualität, die nicht von den Proxys gemessen werden).

Bingo und kein "Wenn". Dies nennt man "Measurement Dysfunction" und es wurde oft beobachtet und geschrieben, wie Joel 2002 einen Artikel darüber schrieb, in dem auf ein Buch eines Harvard-Professors verwiesen wurde.

Das bedeutet nicht, dass solche Metriken nutzlos sind, nur, dass man niemals Anreize oder Richtlinien explizit auf solche Proxy-Messungen stützen sollte. Wenn Sie die Qualität verbessern möchten, ist eine Proxy-Metrik mit einem sehr schlechten Wert wahrscheinlich ein guter Ausgangspunkt. Sie können jedoch nicht zu dem Schluss kommen, dass die Qualität gut ist, nur weil alle Ihre Messdaten hohe Werte aufweisen.

Michael Borgwardt
quelle
3

Was mich interessiert, ist eine tiefere Form der Qualität in Bezug auf das Netzwerk (oder den Graphen) der Typen und ihre Wechselbeziehung, dh auf welche Typen bezieht sich jeder Typ? Gibt es klar identifizierbare Cluster von Interkonnektivität in Bezug auf eine ordnungsgemäße mehrstufige Architektur, oder umgekehrt gibt es eine große "Kugel" von Typreferenzen ("monolithischer" Code).

Das klingt nach Fan-In und Fan-Out. Fan-In zählt die Anzahl der Module, die ein bestimmtes Modul aufrufen, und Fan-Out zählt die Anzahl der Module, die von einem bestimmten Modul aufgerufen werden. Ein zu verwendendes Warnzeichen wären Module mit einem großen Fan-In und einem großen Fan-Out, da dies auf ein schlechtes Design und ein wichtiges Ziel für Refactoring oder Redesign hindeuten könnte.

Außerdem sollte die Größe jedes Typs und / oder jeder Methode (z. B. gemessen in der Menge des Java-Byte-Codes oder .Net IL) einen Hinweis darauf geben, wo große komplexe Algorithmen als monolithische Codeblöcke implementiert wurden, anstatt in besser verwaltbare / wartbare zerlegt zu werden Stücke.

Eine einfache Messung wäre Codezeilen. Sie können es in Codezeilen über das gesamte Projekt und Codezeilen pro Modul aufteilen (möglicherweise mit Modulen unterschiedlicher Größe). Sie können dies als Warnanzeige verwenden, die angibt, dass Sie bestimmte Module überprüfen sollten. Ein Buch über Softwarequalitätsmessungen und -metriken beschreibt einige Arbeiten, die darauf hinweisen, dass die Beziehung zwischen Fehlerraten und Modulgröße krummlinig ist, wobei der durchschnittliche Fehler pro KSLOC bei Modulen mit einer Größe zwischen 175 und 350 SLOC auftritt.

Etwas komplexer wäre die zyklomatische Komplexität, die die Testbarkeit, Verständlichkeit und Wartbarkeit eines Systems anzeigt. Die zyklomatische Komplexität zählt die Anzahl unabhängiger Pfade durch eine Anwendung oder ein Modul. Die Anzahl der Tests und damit der Aufwand für die Erstellung und Durchführung der Tests hängt stark von der zyklomatischen Komplexität ab.

Die genauen Schwellen- / Entscheidungspunkte zwischen hoher und niedriger Qualität sind meines Erachtens subjektiv, da unter Wartbarkeit die Wartbarkeit durch menschliche Programmierer zu verstehen ist und die funktionale Zerlegung daher mit der Funktionsweise des menschlichen Geistes vereinbar sein muss.

Ich bin mir nicht sicher, ob das der Fall ist.

Zum Beispiel gibt es Untersuchungen, die darauf hindeuten, dass das Arbeitsgedächtnis eines Menschen nur 7 plus / minus 2 Objekte aufnehmen kann . Dies ist wahrscheinlich für die Messung von Fan-In und Fan-Out von Interesse. Wenn ich in einem Modul arbeite und es mit mehr als ~ 7 anderen Modulen verbunden ist, kann ich wahrscheinlich nicht genau verfolgen, was diese sind Andere Module sind in meinem Kopf.

Es wurde auch daran gearbeitet, Fehler mit Metriken wie der zyklomatischen Komplexität in Beziehung zu setzen. Da Sie Fehler in Ihrem System minimieren möchten, können Sie Punkte identifizieren, die entweder aufwendiger getestet oder umgestaltet werden müssen, was durch eine hohe zyklomatische Komplexität gekennzeichnet ist.

Ich frage mich auch, ob dies eine gefährliche Idee ist, dass wenn objektive Proxys für Qualität populär werden, der Geschäftsdruck Entwickler dazu veranlasst, diese Metriken auf Kosten der Gesamtqualität zu verfolgen (jene Aspekte der Qualität, die nicht von den Proxys gemessen werden).

Dies ist bei allen Messungen oder Metriken der Fall. Sie müssen verwendet werden, um das System zu verstehen und fundierte Entscheidungen zu treffen. Der Satz "Sie können nicht verwalten, was Sie nicht messen können" fällt Ihnen ein. Wenn Sie hochwertige Software benötigen, benötigen Sie einige Messungen und Metriken, um diese Qualität zu bewerten. Dies hat jedoch eine Kehrseite. Sie können nicht ausschließlich nach den Zahlen verwalten. Sie können die Zahlen verwenden, um fundierte Entscheidungen zu treffen, aber Sie können keine Entscheidung treffen, nur weil die Zahlen dies aussagen.

Thomas Owens
quelle
Die Sache mit Fan-In / Out ist, dass es zwei Zahlen pro Modul / Klasse (oder was auch immer) gibt und daher einige der tieferen Organisationsstrukturen, wie Module verbunden sind, ignoriert. Sie könnten beispielsweise eine kleine Gruppe von Modulen mit hoher Verbindung zu einer logischen Ebene haben und erwarten, dass die Verbindungen zwischen Ebenen (im Vergleich) minimal sind, was eine genau definierte Schnittstelle / einen genau definierten Vertrag zwischen Ebenen darstellt. Ich denke, wir freuen uns, dass einige Module stark miteinander verbunden sind (z. B. häufig verwendete Hilfsmethoden / -klassen), aber abhängig von der 'Struktur' der Konnektivität (das ist meine Hypothese).
Redcalx
@locster Sie möchten es wahrscheinlich erweitern und beispielsweise notieren, in welchen Paketen sich die Klassen befinden, mit denen Sie verbunden sind. Sehen Sie sich nicht nur die unformatierten Zahlen an, sondern unterteilen Sie sie in Dinge wie X-Klassen in meinem Paket, Y Klassen außerhalb meines Pakets oder Z-Klassen in diesem speziellen Paket. Wenn Sie ein Fan-Out zwischen Modulen in Ihrem Datenmodell und Modulen in Ihrer Benutzeroberfläche feststellen, kann dies ein Hinweis auf ein Problem sein. Sie müssen ein wenig tiefer graben als nur die rohen Zahlen.
Thomas Owens
3

Für viele der Eigenschaften, an denen Sie interessiert sind, gibt es Metriken oder Proxies:

  1. Zeilen von Code
  2. Fan in, Fan out
  3. Fehlerrate pro 1000 Codezeilen
  4. Zyklomatische Komplexität
  5. Code-Abdeckung
  6. Entscheidungspunktabdeckung
  7. Fehlerquote, die durch Wartungstätigkeiten behoben / eingeführt wurde
  8. Funktionspunktanalyse

Es gibt einige Probleme mit all diesen Elementen:

  1. Arbeiten zur Optimierung der Metrik - ein universeller Trend; Massiv verschärft, wenn eine der Metriken als Grundlage für die Bewertung oder Belohnung von Teams oder Einzelpersonen verwendet wird.
  2. Mir ist keine Metrik bekannt, die kontextfrei ist. Dies impliziert, dass kein Vergleich zwischen Geschäften möglich ist - nur innerhalb von Geschäften im Laufe der Zeit. Kennzahlen, die sich aus solchen Vergleichen ergeben, sind nach wie vor wertvoll. "Produzieren wir Code jetzt korrekter als vor einem Jahr?"

Der Gesamteffekt dieser Probleme besteht darin, dass Metriken wie diese wahrscheinlich nur innerhalb einer breiteren Kultur von Nutzen sind - wie z. B. TQM, Qualitätssicherung (nicht Kontrolle), kontinuierliche Verbesserung, Kaizan usw. Es ist erforderlich, Elemente beider Kulturen zu definieren und wie es sich ändern muss. Wenn Sie eine Definition dieser Kennzahlen haben, werden Kennzahlen wie diese zu unverzichtbaren Werkzeugen, um die Qualität des Codes, die Arbeitspraktiken, die Produktivität usw. zu verbessern. Ohne diesen weiteren Kontext erzeugen Kennzahlen Arbeit zur Optimierung der Kennzahl. wird zum Werkzeug des Beancounters, um die Produktivität zu steigern und die Kosten zu senken; und wird zu einem Hindernis für die Entwickler.

Chris Walton
quelle
2

Sie könnten von Metriken besessen sein, oder Sie könnten von den besten Leuten, Tools, Praktiken für das Engineering und der Qualitätssicherung besessen sein, die Sie sich leisten können. Ich wäre viel glücklicher, wenn ich mehrere paranoide QA-Genies hätte, die "Fooled by Randomness" gelesen haben und die lieber automatisieren als ein paar gut formatierte Berichte mit Zahlen.

Job
quelle
+1 für Nassim Taleb Buchreferenz. Fehlerhafte Argumentation / Erkenntnistheorie in der Kette der Kausalität für schlechte Qualität.
Redcalx
@locster, dein Kommentar hat mich an den F # -Pipeline-Operator denken lassen :). Sie beginnen mit "Nassim Taleb Buchreferenz", enden aber mit "Kette der Kausalität für niedrige Qualität" (anstelle von "Kette der Kausalität niedriger Qualität"). So wie wir auf Englisch manchmal gerne zwei Arten haben, Dinge zu sagen, ist uns das vielleicht auch in einer Programmiersprache lieber.
Job
1

Es gibt dieses grundlegende Problem mit Metriken.

Es hat sich gezeigt, dass praktisch alle vorgeschlagenen Metriken in der realen Welt mit echtem Code stark oder sehr stark mit rohem SLOC (Quellcodezeilen) korrelieren.

Dies ist, was Halsteads Metriken in den 1970er Jahren tötete. (Durch Zufall habe ich eines Tages, ca. 1978, an einem Vortrag einer neuen Doktorarbeit über Halsteads Metriken teilgenommen, in dem er darauf hingewiesen hat.)

In jüngerer Zeit hat sich gezeigt, dass McCabes zyklomatische Komplexität sehr stark mit dem rohen SLOC korreliert, so dass sich der Typ, der die Studie durchgeführt hat, laut gefragt hat, ob McCabes Metrik überhaupt etwas Nützliches verrät.

Wir wissen seit Jahrzehnten, dass große Programme eher Probleme haben als kleine. Wir wissen seit Jahrzehnten, dass große Unterprogramme mit größerer Wahrscheinlichkeit Fehler aufweisen als kleine. Warum brauchen wir arkane Metriken, um dies zu sagen, wenn das Betrachten von vier Druckerseiten, die über eine Tabelle verteilt sind, überzeugend genug sein sollte?

John R. Strohm
quelle
Um gewartet werden zu können, muss der Code in menschlichen Blöcken vorliegen, daher sieht eine SLOC-Metrik aus dieser Perspektive ziemlich gut aus. Für eine gegebene Größe kann es jedoch eine unterschiedliche Anzahl eindeutiger Pfade geben (je nach zyklomatischer Komplexität), und ich würde argumentieren, dass mehr Pfade ein Proxy für weniger leicht verständliche Pfade ist. Daher würde ich argumentieren, dass CC dem SLOC wahrscheinlich / some / zusätzlichen Wert hinzufügt, solange Sie eine gewisse Flexibilität, Ausnahmen von der Regel usw. zulassen. Das heißt, Sie sollten CC.limits / goals nicht strikt durchsetzen.
Redcalx
1
@locster: Bei zwei 100 SLOC-Modulen hat eines mit einem CC von 47 wahrscheinlich mehr Probleme als eines mit einem CC von 3. Für Code aus der realen Welt stellt man jedoch in großen Mengen fest, dass kurze Module tendenziell niedrig sind CC und lange Module weisen in der Regel einen hohen CC auf, sodass Sie bei Kenntnis des SLOC eine sehr gute Einschätzung des CC erhalten und umgekehrt. Dies ist gemeint mit "sehr stark korreliert". ALS SOLCHE, auf echten Code, ein Nutzen Sie Suche von CC zu bemerken = 47 ist leichter von bemerken SLOC = 1500. bekommt (Zahlen nach dem Zufallsprinzip gezogen, das Prinzip ist das gleiche.)
John R. Strohm
Ja, ich stimme zu, dass sie in der Regel stark korrelieren, obwohl die Beziehung im Allgemeinen nicht linear ist. Beispiel: Ein CC-Score ist ungefähr LOC, das auf eine bestimmte Potenz angehoben wird. Aus psychologischer Sicht wird der CC-Score also sehr schnell sehr groß, während der zugehörige SLOC-Score nur „ein bisschen höher“ zu sein scheint. Ja, ich weiß, ich greife hier nach Strohhalmen :)
Redcalx
@locster: Ich mache das schon seit über 30 Jahren. Heutzutage sehe ich routinemäßig Routinen für Bewusstseinsströme, die für ein paar Hundert SLOC ohne Grund weiterlaufen. In all den Jahren habe ich genau eine (1) Routine gesehen, die eigentlich mehr als eine Druckerseite Code sein MUSS (ungefähr 60 Zeilen). Der Rest hätte durchaus gewinnbringend heruntergerechnet und die Lesbarkeit und Zuverlässigkeit deutlich erhöht werden können. (Das zählt nicht große State Machines. Sie können ein Problem in diesem Bereich sein, aber sie sind selten.)
John R. Strohm
-2

Angesichts all der anderen Antworten hier, fühle ich mich irgendwie albern mit diesem kleinen. Schauen Sie sich Crap4j an , das versucht, Methoden in Java danach zu ordnen , wie sehr sie stinken. (Das Projekt sieht verlassen aus.)

Es verwendet eine Kombination aus zyklomatischer Komplexität und Testabdeckung. Wie jede andere Metrik ist sie spielbar.

Sean McMillan
quelle