Wie bewertet man Code-Qualität? Kriterien, Methoden und Tools im Überblick

Warum Code-Qualität vor allem bei Änderungen wichtig ist

Code-Qualität entscheidet vor allem darüber, wie schnell und sicher Entwickler bestehenden Quellcode verstehen, ändern und testen können.

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?

Welche Regeln verbessern Code-Qualität im Entwicklerteam?

Ein wirksames Regelwerk kombiniert verbindliche Coding Standards, einfache Architekturprinzipien, kontinuierliche Verbesserung und automatisierte Prüfung. Wir haben bestimmte Regeln bei onOffice aufgestellt, um ständig ein hohes Qualitätsmaß 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.

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

Wie lässt sich Code-Qualität im Alltag messen und sichern?

Code-Qualität lässt sich durch eine Kombination aus Code-Reviews, automatisierten Commit-Checks, statischer Analyse, Tests und klaren Verantwortlichkeiten sichern. 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. Genau 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.

Wer Code-Qualität bewerten möchte, sollte nicht nur einzelne Codezeilen prüfen, sondern ein System aus Standards, Reviews, Tests, Architekturregeln und automatisierter Analyse etablieren.