Sonarqube – Codequalität von TYPO3 Extensions automatisiert messen

Als Internetagentur, die einen ihrer Schwerpunkte auf TYPO3 setzt, entwickeln wir natürlich maßgeschneiderte TYPO3 Extensions, die den Anforderungen unserer Kunden entsprechen. Viele Standard-Aufgaben löst man allerdings schon mit den – inzwischen sehr vielfältigen – Boardmitteln von TYPO3.

Falls der TYPO3 Core mal nicht über die gewünschte Funktionalität verfügt, findet man meistens eine Lösung in Form einer Fremd-Extension im TYPO3 Extension Repository (TER). Falls einem bestimmte Aspekte in einer schon vorhandenen Extension fehlen, kann man diese lokal erweitern und durch eine Contribution in das Upstream Projekt allen anderen Benutzern der Extension ebenfalls zur Verfügung stellen. So kann man aufwändige Eigenentwicklungen vermeiden, außerdem will man ja auch nicht jedes mal das Rad neu erfinden.

Im TER findet man viele Extensions die eine hohe Qualität haben, jedoch gibt es auch jede Menge, teils veraltete Extensions, die eine niedrige Codequalität, fehlende Dokumentation oder sogar offensichtliche Sicherheitsmängel haben.

Das Problem: Händische Prüfungen sind sehr zeit- und arbeitsaufwändig

Um beurteilen zu können, ob eine bestimmte Extension in einem Projekt eingesetzt werden kann, reicht es in der Regel nicht, die reine Featureliste aus der hoffentlich vorhandenen Dokumentation zu prüfen. Man will auch wissen, ob der Extension Author sich an die PHP Coding Standards gehalten hat, ob es offensichtliche sicherheitstechnische Mängel gibt und, ob der Code einfach wartbar und erweiterbar ist. Zu guter Letzt ist man ebenfalls sehr daran interessiert, wie aktiv an einer Extension entwickelt wird.

Unter Umständen findet man zu einer gewünschten Funktionalität eine Vielzahl an Extensions im TER, sodass das Ganze mit der Anzahl der verfügbaren Extensions multipliziert wird. Falls man alle Aspekte per Hand prüfen möchte, kommt man natürlich schnell bei einem unverhältnismäßig hohem Zeitaufwand an.

Die oben angesetzten Maßstäbe will man natürlich nicht nur für Fremd-Extensions anwenden, sondern ebenfalls für Eigenentwicklungen: Ziel ist es, in seinem Projekt so wenig technische Schulden wie möglich anzuhäufen. So erhält man die Agilität in der Entwicklung und ist in der Lage, neue Features und Erweiterungen von bestehendem Code schnell und damit auch kostengünstig zu entwickeln. Außerdem erhöht man damit die Zugänglichkeit für codefremde Entwickler, verkürzt somit also Onboarding-Zeiten und man kann in Hochphasen von Projekten auch mal bedenkenlos Externe hinzuziehen.

Unsere Lösung: Das Tool Sonarqube

Wir nutzen hierfür das Tool Sonarqube. Hiermit können wir auf einfache Weise die Codequalität automatisiert analysieren und einfach verständliche Kennzahlen ableiten. Das Tool lässt sich sehr einfach in Deployment Pipelines einbinden. Außerdem können wir uns auch mal schnell einen Überblick über die Qualität von extern geschriebenem Code verschaffen, ohne selbst zu viel Manpower investieren zu müssen. Unsere Entwickler nutzen das Tool in erster Linie, um ihrem hohen Anspruch an sich selbst und ihren Code gerecht zu werden. In zweiter Linie hilft es aber auch bei der Planung von Projekten, in dem es einen ersten Eindruck vermitteln kann, wie viel Arbeit alleine für das Verständnis einer fremden Codebasis erforderlich ist.

Wir haben außerdem jetzt seit knapp über einem Jahr in Zusammenarbeit mit Alexander Schnitzler eine Initiative gestartet, um die Codequalität von Extensions im TER zu messen, und auf einer öffentlichen Plattform zur Verfügung zu stellen. Herausgekommen ist dabei die Seite ter-sonarqube.marketing-factory.de:

Hier prüfen wir alle im TER veröffentlichten Extensions nach den Coding Standards, die wir auch in der MFC für unsere eigenen Projekte verwenden. Regelmäßig scannt das System nach neu verfügbaren Extensions. Außerdem kann man auch die Entwicklung der Extensions nachvollziehen, da wir nicht nur Ergebnisse für die aktuelle Version einer Extension bereitstellen, sondern auch die Ergebnisse aller verfügbaren Versionen eingesehen werden können.

Die Zukunft von Sonarqube für das TER

Marcus Schwemmer hat im September in einem Blogpost die einzelnen Aspekte der Codeanalyse mit unserem Sonarqube Projekt beleuchtet. Hier findet man auch eine Beschreibung des Konzeptes hinter Sonarqube, weshalb ich jetzt nicht darauf eingehe – wer sich für die technischen Hintergründe interessiert, kann gerne in dem Blogpost nachlesen.

Die am Ende genannten Kritikpunkte beziehungsweise Wünsche können wir nur unterstreichen. Solange das ganze Projekt allerdings von unserer Seite aus betrieben wird und wir in Zusammenarbeit mit Alexander Schnitzler Geld und Arbeit in das Projekt stecken, nehmen wir uns auch das Privileg heraus, das Regelset zu bestimmen. Das bedeutet jedoch nicht, dass wir nicht gerne sinnvolle Vorschläge hören und auch gegenüber Contributions jederzeit offen sind. Zukünftig wollen wir das Projekt auf jeden Fall noch weiter verbessern. Alexander Schnitzler arbeitet gerade daran, dass die Informationen aus dem Sonarqube ebenfalls direkt im TER verwendet werden können (git-t3o.typo3.org/t3o/ter/issues/240). Außerdem wollen wir in Zukunft auch die in vielen Extensions schon vorhandenen PHPUnit Tests durchführen und im Sonarqube darstellen.

Ich möchte aber an dieser Stelle auch nochmal betonen, dass wir das Projekt in erster Linie als Hilfestellung für Entwickler und Agenturen im TYPO3 Projektumfeld ins Leben gerufen haben. Das Projekt soll keinesfalls dem Bashing von irgendwelchen Extensions und deren Autoren dienen, sondern das genaue Gegenteil: Es sollen sich viel mehr Extension-Entwickler an diesem Tool bedienen und ihre Programmier-Skills sowie die Qualität ihrer Extensions verbessern. Die generelle Verbesserung der Codequalität kann nur im Interesse aller im TYPO3-Umfeld arbeitenden, Menschen liegen.

Denn am Ende profitieren alle Beteiligten von einer höheren Qualität von TYPO3 Projekten, welche das Vertrauen der End-Benutzer und Kunden in die Marke TYPO3 erhöhen und festigen.