Wie bewertet man Code-Qualität?

In der Softwareentwicklung drehen sich viele Diskussionen um das Thema Code-Qualität. Aber was versteckt sich genau hinter dem Begriff Code-Qualität? Und was ist eigentlich Qualität?

Qualität ist die Gesamtheit der Eigenschaften von Erzeugnissen, die den Grad ihrer Eignung für einen bestimmten Verwendungszweck bestimmt

Großes Fremdwörterbuch, Bibliographisches Institut Leipzig

Qualität in Bezug auf Sourcecode?

Bezogen auf die Code-Qualität ergeben sich allerdings neue Fragen. Was ist der Verwendungszweck des Programmcodes im Sinne guter Qualität? Und was sind die Eigenschaften des Codes?

Geschriebener Quellcode hat zwei Verwendungszwecke. Er wird ausgeführt und geändert. Für die Ausführung ist die Code-Qualität nur bedingt wichtig. Der Code sollte dafür fehlerfrei sein, was bei guter Qualität einfacher zu erreichen, aber nicht zwingend notwendig ist. Für die Änderung vom Quellcode ist die Qualität deutlich wichtiger. Je häufiger eine Code-Stelle überarbeitet wird, desto wichtiger sind die Qualitätsanforderungen. 

Die Frage nach den Eigenschaften zur Bewertung der Qualität lässt sich durch eine ISO-Norm beantworten.

Qualitätsmerkmale Software nach ISO 9126

Die ISO-Norm legt folgende Bereiche für Qualitätsmerkmale einer Software fest:

  • Zuverlässigkeit
  • Effizienz
  • Übertragbarkeit
  • Funktionalität
  • Benutzbarkeit
  • Änderbarkeit

Wie eben festgestellt, ist die Code-Qualität immer dann sehr wichtig, wenn Code geändert wird – der letzte Bereich ist besonders spannend.

Als Unterpunkte nennt die ISO-Norm:

  • Analysierbarkeit
  • Modifizierbarkeit
  • Stabilität
  • Testbarkeit

Um eine gute Code-Qualität zu gewährleisten, muss der Code verständlich, änderbar, stabil und testbar sein. Die logische nächste Frage ist: Was sollte man beachten, um dies zu erreichen?

Regelwerk für Code-Qualität

Wir haben bestimmte Regeln bei onOffice aufgestellt, um ständig ein hohes Qualitäsmaß unseres Quellcodes sicherzustellen.

Styleguide

Grundlage für eine gute Analysierbarkeit in einem großen, wachsenden Entwicklerteam ist ein einheitlicher Programmierstil. Der Styleguide stellt verpflichtende Regeln für Stil, Konventionen und Standards auf.

Unser Regelwerk wurde bereits vor über zehn Jahren eingeführt. Bestehende Regeln dürfen jedoch technologischen Fortschritt niemals blockieren, weshalb unser Styleguide regelmäßig angepasst oder erweitert wird.

Clean Code

Clean Code ist der Quasi-Standard für leicht verständlichen Quellcode. Alle Entwickler sind angehalten, Clean-Code-Regeln zu beachten.

Pfadfinderprinzip

Das Pfadfinderprinzip ist keine Regel, die den Quellcode direkt betrifft, sondern eine kontinuierliche Verbesserung der Code-Qualität. Das Pfadfinderprinzip besagt, dass der eigene Lagerplatz immer ordentlicher verlassen werden sollte, als man ihn vorgefunden hat. Findet man Abfall vor, sollte kein weiterer Unrat hinzugefügt werden. Man nimmt den hinterlassenen Müll mit und entsorgt ihn.

Falls das zu abstrakt ist:

  • der Lagerplatz ist der Programmcode
  • die Pfadfinder sind die Entwickler
  • Der Abfall steht für schlechte Code-Qualität

Erweitert man also eine bestehende Code-Stelle, die nicht optimal ist, darf das keine Ausrede dafür sein, Regeln zur Code-Qualität zu missachten. Im Gegenteil: Da man die Stelle sowieso anpasst und testet, sollte man die Qualität direkt insgesamt erhöhen.

KISS

Das KISS-Prinzip (Keep it simple, stupid) wird oft unterschätzt, stellt aber sicher, dass Programmcode verständlich, stabil und testbar ist. Wenn mehrere Lösungen für eine Implementierung gefunden werden, sollte immer die einfachste gewählt werden.

SOLID

Die SOLID-Prinzipien greifen auf der höheren Ebene der Software-Architektur in die Code-Qualität ein. Bewegten sich die bisherigen Regeln im Bereich Analysierbarkeit und Stabilität stellen die SOLID-Prinzipien eine gute Modifizierbarkeit von Quellcode sicher.

Testgetriebe Entwicklung (TDD)

Zu jeder Klasse und jeder Anpassung wird bei uns parallel ein Unit-Test erstellt oder erweitert. Das Kriterium der Testbarkeit ist damit direkt erfüllt, da man schon bei der Implementierung gezwungen ist, die Testbarkeit sicher zu stellen.

Qualitätsmanagement

Das Ziel der hohen Code-Qualität muss natürlich auch gemanaged werden. Klar definierte Ziele haben wir festgelegt, die Einhaltung dieser Ziele muss allerdings bewertet und gesteuert werden.

Review bei Commit

Beim Commit führen Entwickler in eigener Verantwortung Code-Reviews mit Kollegen durch. Hat jemand den Eindruck, dass eine Änderung durch ein direktes Review abgesichert werden sollte, ruft er einen Kollegen und erklärt ihm die Anpassung im direkten Gespräch.

Commit-Checks

Vor jedem Commit wird ein selbst entwickeltes Script zur Prüfung des Commits ausgeführt. Vorteil der Eigenentwicklung ist, dass wir die Prüflogik regelmäßig erweitern und an bestehende Regeln anpassen. Unsere Produkte sind alle in einem Schichtenmodell aufgebaut und Abhängigkeiten darf es nur nach innen geben. Denau diese prüft die Logik zum Beispiel.

Das Commit-Check-Script:

  • prüft bestehende Styleguide-Regeln
  • führt vorhandene Unit-Tests aus
  • führt phpStan zur Analyse der geänderten Stellen aus
  • prüft Abhängigkeiten im Schichtenmodell

Review-Ticket

Jede Änderung erzeugt ein Review-Ticket für eine Gruppe von ausgewählten Entwicklern. Die Reviewer prüfen die Änderung noch einmal gesondert und geben dem Entwickler eventuelle Hinweise auf Verbesserungen oder nicht eingehaltene Regeln. Natürlich gilt: Alles, was die Automatisierung schon getestet hat, darf im manuellen Review nicht mehr auftreten.

sonarQube

Zusätzlich verwenden wir sonarQube als statische Code-Analyse. Aus neuen Fehlern oder Warnungen werden wieder Tickets für den entsprechenden Entwickler erstellt.

Fazit

Unsere CRM-Software wurde vor mehr als 15 Jahren entwickelt. Über die Jahre gab es natürlich größere Überarbeitungen und Refactorings. Im Prinzip entwickeln wir aber seitdem ein immer weiter wachsendes CRM-Tool.

Ohne den klaren Fokus auf Code-Qualität und ohne stetige Weiterentwicklung der Regeln wäre das nicht möglich gewesen. Ohne diesen Fokus könnten wir heute nicht so effizient arbeiten, wie wir es gerade tun.

2 Gedanken zu “Wie bewertet man Code-Qualität?”

  1. „Beim Commit führen Entwickler in eigener Verantwortung Code-Reviews mit Kollegen durch.“
    Reicht das wirklich aus, um die Qualität im Code hinreichend zu sichern? Muss hier nicht gezwungenermaßen immer ein Review stehen oder wird dies durch das Review-Ticket später abgedeckt?

    „Aus neuen Fehlern oder Warnungen [im sonarQube] werden wieder Tickets für den entsprechenden Entwickler erstellt.“
    Wird daraus ein schönes volles Backlog oder wie wird damit umgegangen?

    Insgesamt ein sehr schöner Artikel, der die wichtigsten (bis auf eines) Prinzipien nennt. Ich freue mich, wenn es Teams schaffen, sich daran zu halten. Dennoch fehlt mir https://de.wikipedia.org/wiki/DRY. 🙂

    Freundliche Grüße
    Michael Ecker

    1. Hallo Michael,

      genau, durch das Review-Ticket sichern wir ab, dass wirklich jeder Commit geprüft wird. Das freiwillige „direkte“ Review hat da einfach einen anderen Fokus, der umsetzende Entwickler erklärt seine Änderungen dem Reviewer, was oft völlig andere Ergebnisse erzeugt, als das getrennte Review „in Ruhe“.

      Die Tickets zu sonarQube-Nacharbeiten landen direkt wieder beim Entwickler und legen sie nicht in ein blackhole – hier verstoßen wir bewusst(!) gegen Kanban/Pull-Prinzip.

      DRY: Das Vermeiden und Entfernen von Code-Duplizierungen ist seit Jahren hier natürlich auch ein riesen Thema. Es steht aber mittlerweile immer öfter zur Diskussion, deswegen hatte ich es nicht mit aufgenommen. Zum Beispiel kommt immer öfter die Frage auf, was eigentlich duplizierter Quellcode ist. X Zeilen, die aktuell exakt gleich sind, müssen kein duplizierter Quellcode sein. Wenn es um logisch unterschiedliche Bereiche geht, kann es (gerade in einem großen Entwicklerteam) besser sein, eine solche „Duplizierung“ entstehen und sich weiterentwickeln zu lassen, als eine Vereinheitlichung zu erzwingen, die dann blockiert. Vor einem halben Jahr hätte ich dir noch voll zugestimmt, in dem Bereich hat sich meine Meinung über die letzten Monate geändert.

      Gruß
      Janosch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

18 − 4 =