Softwaremetriken - wie macht man das heute?

Hallo,

ich recherchiere gerade zum Thema Software-Metriken. Und ich finde zu dem Thema nur sehr Alte Dinge. Die Halstead-Metrik gibt es ja zum Beispiel seit 1977.

Die Softwareentwicklung hat sich ja eigentlich in den letzten 40 Jahren "ein klein wenig" verändert. Verwendet man trotzdem noch so alte Metriken um die Qualität/ Komplexität des Codes zu messen?

Kann mir hier jemand vielleicht sagen, wie man das Moderner macht?
Oder gute Literatur dazu empfehlen?

Danke schonmal

Hi,

ich kenne bisher keine Metrik, die aktuell eingesetzt wird. Was man heutzutage macht sind automatisierte Tests. Wer ernsthaft noch meint, über die Qualität des Codes etwas aussagen zu können, nachdem die Lines of Code gezählt werden, lebt in meinen Augen hinterm Mond.

"Qualität" ist bei Code grundsätzlich ein sehr diskussionswürdiger Faktor. Was man bewerten kann:

- Funktionalität: macht der Code, was er soll?
- Testbarkeit: macht der Code, was er soll, ohne dass dadurch andere bestehende Funktionen in Mitleidenschaft gezogen wurden? Wie viel vom Code wurde getestet?
- Einhaltung von Konventionen: ist der Code grundsätzlich so aufgebaut, wie vereinbart (Bezeichner, Kommentare etc)

Das reicht in meinen Augen völlig und ich habe es bisher auch bei keinem Kundenprojekt anders gesehen.

VG,
Mad

• Lesbarkeit
• Übersichtlichkeit
• Verständlichkeit
• Erweiterbarkeit
• Vermeidung von Redundanz
• Testbarkeit

Link: Refactoring

Es jede Menge statische Code Analyse Tools. Für Python benutze ich z.B. http://pylint.org/
Je nach Tool fliessen eben verschiedene Metriken mit ein. Automatic Test Coverage ist ziemlich wichtig, aber auch Code Formatierung usw.

Es gibt heutzutage Tools, die dir die Metriken deiner Wahl automatisch (und in der Regel im Rahmen eines Continuous-Integration-Systems) berechnen. Ein bekanntes solches Tool ist PMD. In seinem Regelsatz findest du u.a. die zyklomatische Komplexität und die n-Pfad-Komplexität, die mE aktuell die beiden gängigsten Komplexitätsmaße sind.

@Madman1209: Dem kann ich nur eingeschränkt zustimmen. Zwar hast du sicherlich recht, dass die Einhaltung von Komplexitätsregeln noch keinen guten Code ausmacht, andersherum ist es mE allerdings durchaus so, dass hohe Komplexitätswerte recht sicher auf schlechten Code schließen lassen.

- Zu tiefe Verschachtelung von verzweigungen
- unpassende modifier
- nicht benutzte variabeln
- bekannte anti-pattern
- God-Classes
- Zu komplexe Funktionen
- Auskommentierter Code
- Code Coverage
- Condition Coverage

Kann alles automatisch analysiert werden. Sicher noch viele mehr, welche ich vergessen habe

Hi,

@NullPointer

Das mag sein, aber LoC bedeutet auch nicht zwingend Komplexität Dass zu komplexer idR schlechter ist als einfacher, da gehen wir absolut in die selbe Richtung.

VG,
Mad

Vielen Dank schonmal für eure Antworten!!!

Ich hab an dieser Stelle aber noch eine Frage dazu, bzw. eine Erläuterung zu dieser Frage:

Wir haben in meinem Ausbildungsbetrieb eine selbst entwickelte Domain Specific Language. Und ich soll eine wissenschaftliche Arbeit dazu schreiben, wie der Quellcode, der in dieser DSL geschrieben wurde, bewertet werden kann.
Ich soll in diser Arbeit herausfinden, welche Metrik am besten verwendet werden sollte. Und wie das Ergebnis der Metrik hinterher interpretiert werden kann. Z. B. soll das Halstead-Volumen in einem C-Programm zwischen 20 und 1000 liegen. Ich soll herausfinden welche Werte für unsere DSL gut sind.

Der Hintergrund ist, wenn man mehrere 1000 Dokumente hat, die Quellcode beinhalten. Wie findet man schnell und einfach Codeabschnitte, die man sich nochmal anschauen könnte, weil sie statistisch gesehen die meisten Fehler enthalten oder am Komplexesten sind. -> Es soll aber auch frischer Code gleich mitbewertet werden.

Mein Problem:
Meine Hochschule will, dass die verwendete Literatur nicht mehr als 3-4 jahre alt ist (außer in Ausnahmefällen). Das was ich zu Softwaremetriken finden kann, ist jedoch alles sehr viel älter.

Denkt ihr, solche Metriken machen heute gar keinen Sinn mehr?

Nö, denke ich nicht, aber es wird nicht ständig neue Literatur zu etablierten Themen produziert. 3-4 Jahre alte Bücher fallen selbst im Bereich der Softwareentwicklung fast noch in die Kategorie "brandneu". Sich darauf zu beschränken halte ich nicht für sinnvoll.

Edit: Vielleicht ist das hier ja einen Blick wert:

http://www.amazon.com/Software-Metr...d=1427880103&sr=1-1&keywords=software+metrics

3. Auflage von 2014, könnte also von deiner Uni als neu durchgehen, auch wenn die erste Auflage schon 1991 herauskam

Dann sieh dir mal ein paar Bücher zu Design Patterns an welche noch regelmässig zitiert werden. Gang of Four, oder Martin Fowler sind deutlich älter als 3-4 Jahre und trotzdem sind deren Aussagen auch heute noch aktuell und relevant. Ich denke das kannst du nicht verallgemeinern mit "nicht älter als 3-4 Jahre".