Kategorien
Softwaremetriken
Heute mal wieder ein Thema, das ich liebe. Softwaremetriken. Aber wenn ich es liebe, warum schreibe ich erst nach über einem Jahr das erste mal wirklich drüber? Naja Softwaremetriken sind nicht so einfach zu verstehen und damit sind sie auch nicht unbedingt einfach zu beschreiben. Ob ich das jetzt besonder gut hinbekommen werde, weiß ich natürlich nicht. So wie ich euch kenne, werden wir trotzdem am Ende des Tages eine „perfekte“ Definition zusammengebracht haben. Unglaublich, wie ich es immer wieder schaffe euch zum Kommentieren zu bringen.
Was sind also Softwaremetriken? Eigentlich sind sie Funktionen, die ein Stück Software nehmen und daraus einen Zahlenwert berechnen. Hoher Wert ist schlecht, niedriger Wert ist gut (manchmal auch andersrum). Natürlich erkennen wir aus dem Satz schon, warum die Metriken entstanden sind. Wir machen also Code damit messbar und können damit eine Aussage treffen über die Qualität. Zumindest bekommen wir ein ungefähres Gefühl.
Wir können uns also ein Stück Code nehmen, Metriken drüber laufen lassen und dann sagen, ob der Code gut oder schlecht ist. Da es sich hier aber um statische Codeanalyse handelt (zumindest bei den Metriken, die wir hier behandeln), können wir eigentlich nur was zur Wartbarkeit, Architektur und Übersichtlichkeit sagen. Alles was zur Laufzeit gehört, wie Speicherverbrauch oder Geschwindigkeit können wir nicht so schnell abdecken.
Um das ganze ein wenig konkreter zu machen, hier ein einfaches Beispiel. Vielleicht sogar die einfachste Metrik. Lines of Code einer Methode. In dieser Metrik haben wir eine ganz einfache Funktion, um den Quellcode in einen Zahlenwert umzuwandeln. Wir Zählen einfach die Zeilen, der Methode und das ist unsere Zahl. Dabei gehen wir davon aus, dass eine Methode leichter zu warten ist, je kürzer sie ist. Ich würde mal sagen, dass alles unter 40 Zeilen vertretbar ist für eine Methode. Falls die Metrik also einen Wert über 40 ausspuckt, sollte man sich die Methode noch einmal anschauen.
Das war jetzt natürlich eine sehr einfache Metrik. Trotzdem erfüllt sie alle Eigenschaften und ist somit ein vollwertiges Mitglied dieser Familie. Wichtig ist hierbei eigentlich nur, dass wir uns merken, dass Metriken Quellcode auf Zahlen abbilden und damit messbar machen. Solche Umwandlungsformeln können beliebig komplex werden und jeder kann sich seine eigenen Regeln erstellen. Trotzdem gibt es aber einige Metriken, wie zum Beispiel die nPath Complexity oder die McCabe Metrik, die quasi zum Standard geworden sind.
Ich würde einfach mal vorschlagen, dass ich mir die nächsten Wochen ab und zu mal eine Standard-Metrik herausnehme und ein wenig darüber erzähle. Tools, die schon viel für uns machen, werde ich auch vorstellen.
Was mich bei dem Thema interessiert… Relation… Was sind gute Werte, was sind schlechte Werte? Wenn ich mir solche Tests schreibe, woher weiss ich was schlecht ist, was gut ist? Weiß jemand was ich meine? 🙂
Ein relevanter Punkt, der gerne übersehen wird wenn man mit Metriken arbeitet, einige davon sind zwar nett anzusehen, aber es gibt nicht direkt gute oder schlechte Werte. Die Länge einer main-Methode/Funktion in JAVA oder C++ wird zum beispiel meistens etwas länger sein und unter Umständen etwas mehr machen (Anzahl Funktions-Aufrufe) als andere Funktionen/Methoden, da muss man dann nicht anfangen und zwangsoptimieren nur um in ein „Raster“ zu passen.
Es macht auch nicht immer Sinn auf Teufel komm raus auf irgendwelche Metriken hin-zu-optimieren, gewisse Metriken bieten einfach nur nette statistische Werte an und sagen nicht unbedingt direkt etwas über die Qualität aus, bzw. die Qualität wird nicht unbedingt besser, nur weil man alles geändert hat und die Werte „grün“ werden.
Das ganze ist natürlich abhängig von der verwendeten Metrik, aber um mal ein Beispiel:
Nur weil eine Datei „nur“ 10-15 Lines of Code hat (z.b. ein Kleines Interface mit einer Methode + Kommentar) oder 3000-5000 (z.b. Zend_Form oder Zend_Date), muss man da nicht zwangsläufig eingreifen nur weil die Werte extrem niedrieg oder hoch sind, teilweise erfüllen die Klassen/Interfaces eben genau so ihren Zweck und lassen sich nicht besser zusammenfassen oder aufteilen.
@robo47; Das hast du auf jeden Fall recht. Da werde ich auch ein schönes Beispiel zeigen bei der Cyclomatischen Komplexität, wollte ich mir noch noch ein wenig aufheben 😉
Scheint ein interessantes Thema zu sein, aber ich habe dazu einige Fragen. Wie aussagekräftig sind solche Metriken überhaupt? Wofür und wo verwendet man sie? Dienen sie nur Diagnose auf unschöne Programmteile?
Die Frage nach guter bzw. schlechter Metrik ist einfach zu beantworten.
Gut: jedes Modell, was ausreichend nah an der Wirklichkeit ist um dich weiter zu bringen. Schlecht: alles was dir nichts hilft.
Zum Beispiel wenn eine Metrik zeigt, zu wie vielen externen Klassen Abhängigkeiten in einer Funktion aufgebaut werden. Bzw. wie die Anzahl der externen Aufrufe gruppiert nach Quell- und Zielklassen.
Das wäre ein Hinweis auf die Stärke der Kopplung.
Man sieht es schon: Metriken sind Zahlen. Genauer eine Faktentabelle die man nach mehreren Dimensionen gruppieren kann.
Schon sind wir ein Stück näher an der Wahrheit: Erstellung, Darstellung und Auswertung von Softwaremetriken hat Ähnlichkeit mit der Überwachung, Analyse und Bewertung von Prozessen im Bereich Business Intelligence.
Wer will und etwas weiter ausholen möchte, kann sie also auch mit den Methoden eines Data-Warehouse erläutern oder sich Metriken zumindest anhand des Star-Schemas verdeutlichen.
Selbstverständlich bedeutet das auch, dass das Auswerten einer einzelnen Messreihe nicht so aufschlussreich ist, wie mehrere Metriken zu verwenden und diese Daten miteinander in Verbindung zu setzen.
Weil es nämlich auf die Frage: „welche Funktion verdient ein Refactoring?“ je nach betrachtetem Szenario mehr als eine Antwort geben kann. Erst wenn man die Ergebnisse mehrerer Szenarien übereinander bringt, kann man Prioritäten erkennen.
Metriken sind folglich auch aufwendig. Man sollte stets nur so viel Zeit darauf verwenden, wie wirtschaftlich sinnvoll ist.
Ich hab (leider noch) keine tiefe Erkenntnis von Metriken und hatte auch noch nicht die Zeit mich damit auseinander zu setzen. Daher bin ich gespannt auf die kommenden Artikel.
Aber jetzt schon hab ich den Eindruck, dass Metriken in erster Linie nicht dazu da sind die Qualität von Code zu beschreiben, sondern es sind eher „Warnleuchten“. Wenn also eine Metrik „aufleuchtet“ sollte man sich den Code ein zweites mal anschaun. Gibt es eine Begründung für den „Verstoß“ ist alles im grünen Bereich.
Ich halte ziemlich wenig von Software-Metriken.
Am Ende eines großen Projektes mal die Lines of Code zu sehen ist interessant, sagt aber nichts dazu aus, ob es gut oder schlecht ist.
Wie robo47 schon sagte, es gibt schlechte Methoden oder Klassen, die nur auf 20 Zeilen bestehen, und es gibt sehr gute sinnvolle Klassen, die 3000 Zeilen haben. Man kann anhand dieser Zahl fast nichts sinnvolles über die Software lernen oder sie bewerten.
Auch andere Metriken, die den Projekt-Aufwand abschätzen oder irgendwelche Werte über Komplexität ausspucken, sind häufig dem gesunden Menschenverstand und Erfahrung unterlegen.
Interessanter sind da schon Informationen zB zu Pfadabdeckung oder Codeabdeckung bei Unit-Tests. Die kann man schon eher ranziehen, um die Qualität oder Fehlerfreiheit ungefähr zu bestimmen. Wenn man natürlich falsche oder schlechte Tests schreibt, hat man davon auch nichts. Zeitmessungen sind auch relativ gut, weil objektiv und vergleichbar (durch gute Geschwindigkeit büßt man allerdings meistens Lesbarkeit/Wartbarkeit ein). Beides sind Verfahren, die nur am „laufenden Code“ messbar sind, und nicht statisch am Code gemacht werden können. Alles hat seine Vor-und Nachteile.
Wenn man diese Zahlen ÜBER EINEN GROßEN ZEITRAUM misst, kann man daraus evtl. etwas lernen. Einmalige Messungen sind eher uninteressant.
Sehr interessantes Thema. Ich muss aber gleich mit Kritik beginnen ;-).
Metriken nicht mitnichten nur auf Sourcecode beschränkt.
Eine grobe Einteilung wird häufig in die drei Bereiche Produkt, Prozess und Ressourcen vorgenommen.
Und selbst im Produktbereich werden Metriken nicht immer auf Sourcecode-Ebene definiert.
Nennenswert sind hier insbesondere die Metriken von Chidamber&Kemerer zu Objekt-orientierten Design.
Es ist hoffentlich klar, warum man nicht erst damit beginnen sollte die Qualität des Designs zu messen, wenn der Sourcecode bereits vorliegt…
Ich bin natürlich trotzdem sehr auf die folgenden Artikel zu Serie gespannt.
@phpGangsta: würdest Du dir eigentlich ein Auto kaufen bei dem der Verkäufer sagt „Es ist ziemlich schnell“, „Verbraucht etwas Sprit“ und „Hat mehr als eine Tür“?
Ach ja und es muss „so Pi mal Daumen alle paar Monate in die Werkstatt sonst geht der Motor kaputt“
Ein sehr nettes Intro zum Thema, ich freu mich auf die folgenden Artikel
Wenn ich Software kaufe, verlange ich selten Software-Metriken vom Hersteller. Einige Kennzahlen sind informativ, aber sagen wie gesagt nicht allzuviel aus. Viele LoC beeinflussen nicht meine Kaufentscheidung. Eine gute Qualitätssicherung (Codeabdeckung etc) evtl. schon eher. Die Feature-Liste, der Name des Herstellers und der Support sind mir persönlich wichtiger als Kennzahlen zur Komplexität, oder ob da nun eine 3 oder 5 bei der Messung der Objektorientiertheitsmessung rauskommt.
Trotzdem entscheidet im Endeffekt wohl doch das Bauchgefühl, die Erfahrung und die Meinungn anderer Kollegen und Nutzer der Software.
Nochmal zu deinem Beispiel mit dem Auto: Das sind Grundmerkmale eines Autos, die muss man als Käufer natürlich wissen. Genauso wie man die Features und Preis einer Software kennen muss, bevor man sie kauft.
Ob an dem Auto aber nun 20 oder 30 Personen gearbeitet haben bei der Herstellung, ob das Plastik nun aus Spanien oder Argentinien kommt oder ob die Elektronik des Klima-Anlagen-Knopfes nun 40 oder 90% Codeabdeckung hat ist mir alles relativ egal.
Hauptsache das Auto funktioniert, der Hersteller ist bekannt , mir Bekannte sagen: „Das Auto ist super“ und ich im Fehlerfall guten Support habe. Das finde ich wichtiger als irgendwelche internen komplexen Kennzahlen, die man als Nutzer nicht bemerkt.
Die Software funktioniert und ist leicht und schnell zu bedienen: mich interessieren Kennzahlen des Quellcodes nicht die Bohne.
Oder hast du dich für die Metriken deines Betriebssystems (Linux, Windows) interessiert? Wahrscheinlich nicht. Die Benutzung, Preis und Empfehlungen anderer sind da wichtiger.
@Martin: Da hast du natürlich recht. Habe auch grad ein Buch von einem netten Arbeitskollegen auf dem Schreibtisch liegen, da sind jede Menge Prozessmetriken (bzw. Prozessmaße) drinnen. Vielleicht kennst du das ja 😉
@PHPGangsta: Ich glaube schon, dass SWMetriken da was aussagen können. Methoden, die zig Verzweigungen haben, würde ich zum Beispiel nicht gerne in meinem Projekt sehen, weil ich weiß, dass es irgendwann mal Probleme bereiten wird.
@Nils: Ich sage ja nicht, dass sie völlig sinnlos sind. Sie sollten aber auch nicht überschätzt werden. Wie du schon sagtest, gesunder Menschenverstand und Erfahrung beim „Drübergucken“ ist mehr wert als Entwickler.
Wenn ein anderer Mitarbeiter Commits macht, dann schaue ich mir auch lieber kurz an, was er da gemacht hat, als Metriken errechnen zu lassen und ihm dann vorzuwerfen, er hätte schlechte Arbeit gemacht.
@PHP Gangsta: Da hast du natürlich recht. Das ist aber auch nicht der Workflow, den ich empfehlen würde. Metriken sind im besten Fall automatisiert zu berechnen und ein Indiz dafür, dass was nicht stimmen könnte (muss nicht sein).
Code Reviews, die du beschreibst, sind immer noch das effektivste Mittel um Fehler zu finden. Da kann ich Code Complete (Microsoft Press) empfehlen, da ist alles wunderbar beschrieben. Da gebe ich dir also auf jeden Fall recht.
Ich finde übrigens nicht, dass man Unit Testing und Softwaremetriken irgendwie zusammenwerfen darf. Eine super getestete Software kann immer noch grausam zu warten sein. Andersrum kann eine toll designtes Projekt viele Fehler haben.
Haben also andere Anwendungsbiete.
@nils, findest du es nicht ein bisschen schwach als Informatiker überhaupt über Metriken zu schreiben und dann auch noch LOC als Beispiel aufzuführen? Selbst komplexe Verfahren wie Function-Point und COCOMO sind Grundlagen der ersten Semester und bereits in den meisten Entwicklungsumgebungen implementiert.
Wieder mal so ein Artikel, den die Welt nicht braucht 🙂
@snoopy Stimmt … jetzt wo du es sagst. Beim Informatikstudium fängt man im ersten Semester mit Function Points an, in allen PHP IDEs sind Metriken bereits integriert und jeder PHP Entwickler hat Informatik studiert. Hatte ich total vergessen. Sorry mein Fehler.
Ich denke statische Metriken sind nur als hinweise zu betrachten. Aber je früher man sich die Statistiken vor Augen hält, desto besser kann man evtl. dagegen steuern. Und Ich bin der Meinung das eine Klasse die ein Loc von über 3000 durch aus schlecht ist, da kann der Nutzen der Methoden noch so gigantisch sein. Soweit ich mich erinnere unterscheidet z.B phploc durchaus zwischen Komentaren und Code.
Entscheidend ist, bewusst Metriken von Anfang an zu verwenden und diese auch in die Analyse immer wieder mit einzubeziehen.
Die Metriken dürfen auch nicht nur einen Aspekt betrachten, sondern sollten so viele Themenbereiche abdecken wie möglich.
Allerdings muss auch der Beweggrund ein konstruktiver sein.
In Continous Integration Umgebungen hat man die Möglichkeit zu sehen, welcher Entwickler den letzten Build zerschossen hat und wie viel Prozent gesamtschuld dieser Entwickler an allen fehlgeschlagenen Builds hat. Ich halte Personen bezogene Daten z.B für völlig überflüssig, weil sie eine Diskussion aufwerfen die meistens in die falsche Richtung führt.
@Tom
>> Gibt es eine Begründung für den “Verstoß” ist alles im grünen Bereich.
Ich finde man sollte in der Entwicklung so streng (mit sich) sein wie es nur geht – also keine Ausnahmen. Wegen ein zwei stellen gerät natürlich das Projekt nicht in Schieflage. Aber diese Einstellung kann sich Potenzieren, je mehr Entwickler an einem Projekt arbeiten. Da verweise ich gerne an den „Pragmatischen Programmierer“ zum Thema Eingeschlagenen Fensterscheibe. Und Hand auf Herz, wenn wir sagen „Das mache ich Später ordentlich“ wird meistens ein „Das mach ich nie“
@Volker Dusch
Loc wurde nur als Einführunsbeispiel verwendet, weil es sehr schnell greifbar ist (jedenfalls ist der Aufreißer bei mir so angekommen). Natürlich ist mir als Benutzer die allgemeine Qualität des Codes schnurz, aber mir ist nicht egal wenn das Programm alle 5 Minuten anfängt nicht mehr Benutzbar zu werden.
Und das hat wiederum mit der Allgemeinen Qualität zu tun.
@Nils Merci für die gebrochene Lanze für nicht studierte Informatiker.
Interessamtes Thema, muss ich mir wohl doch mal näher ansehen. Informatik hab ich einige Semester studiert, gehört hab ich (zumindest an der Uni) nie was davon.
Eine Buch-Empfehlung die ergänzend zu dem Thema passt: „Clean Code“ von Robert C. Martin. Wenn einem die Metrik sagt, dass der Code kein großes Licht am Entwicklungshimmel ist, dann wird einem in diesem Buch geholfen, den Sauhaufen zu sortieren. Die beschriebenen 40 Zeilen pro Methode werden einem in diesem Buch ausgetrieben 😉
Ich hätte hier eine schöne Liste mit potentiellen Eigenschaften von Code die zum erstellen von Kennzahlen für die Softwaremetriken sinnvoll sind.
http://freeworld.thc.org/root/phun/unmaintain.html
Nebebei gibts noch die Code Smells von Fowler von denen viele auch mit Tools gefunden werden können.
Das Thema finde ich recht interessant. Zum Eintsieg würde mich interessieren ob jemand eventuell einen Tipp/Plugin hat statische Metriken in Eclipse durchlaufen zu lassen.
@Christian Kehres: Sorry habe gerade erst gemerkt, dass deine Frage ja noch gar nicht beantwortet ist. Kannst du sie vielleicht nochmal umformulieren? Was meinst du mit Relationen? Wie Klassenabhängigkeiten zu werten sind? Oder vielleicht Datenbank?