TYPO3 Camp Rhein Ruhr 2015 – Recap 2: Wie man Code Qualität lebt

Am vergangenen Wochenende, vom 14. bis 15.11.2015, war erneut das Unperfekthaus in Essen zum wiederholten Male Mittelpunkt der TYPO3 Community. Wie bereits in den Jahren zuvor trafen sich  TYPO3 Interessierte, aus NRW und entfernteren Regionen, zum Erfahrungsaustausch mit Gleichgesinnten zum TYPO3 Camp Rhein-Ruhr #T3CRR.

Am Samstag startete pünktlich um 10.00 Uhr die Event-Eröffnung durch Benjamin Kott, der auf’s Podium gestiegen war um die über 170 Teilnehmer im großen Saal des Unperfekthaus zu begrüßen. Das Team von web-vision war mit sieben Teilnehmern traditionell stark auf dem #T3CRR vertreten.

Wie auf einem Barcamp üblich gab es auf dem #T3CRR, im Gegensatz zu einer Konferenz  keinen festen Plan für Präsentationen, Workshops oder Talks. In der Session Planung konnten statt dessen Teilnehmer einen Themenvorschlag dem Publikum unterbreiten. Das Publikum konnte dann per Handzeichen über das Thema abstimmen. Je nach Anzahl der Interessenten wurden dann die unterschiedlichen Räumlichkeiten nach Publikumsgröße zugeteilt.

Nach einer spontanen Abstimmung zwischen Daniel und mir (Boris), kamen wir zu dem Schluss das Thema „Code Qualität analysieren und dauerhaft im Agenturbetrieb einsetzen“ mit dem Thema „In 5 Minuten zum TYPO3 Core Contributor“ kombiniert anzubieten.  Erfreulicherweise kamen auch genügend Interessenten zustande, so das wir direkt den ersten Slot um 11.00 Uhr erhielten, um im Raum 404 letztendlich unseren Talk halten zu können.

Vortrag: Code Qualität analysieren und dauerhaft im Agenturbetrieb einsetzen, Technische Schulden, Sonarqube (Bild: © https://twitter.com/jouschcom )

Vortrag: Code Qualität analysieren und dauerhaft im Agenturbetrieb einsetzen, Technische Schulden, Sonarqube (Bild: © https://twitter.com/jouschcom )

Technical Debts (technische Schulden)

Wieso man diesen frühzeitig begegnen sollte!

Zu Beginn unseres Talks gingen wir auf anhand der folgenden Skizze ein, wie sich in der Software Entwicklung technische Schulden einschleichen.

Technische Schulden

Technische Schulden

Häufig steht man am Anfang der Entwicklung einer neuen Software, wie zum Beispiel einer neuen TYPO3 Website oder eines Online Shops, freudig der Entwicklung entgegen. Alle Projektteilnehmer sind gespannt auf das Projekt und sowohl die Agenturleitung, der Kunde und letztendlich auch die Entwickler sind voller Inbrunst eine saubere und auf dem technischen Höhepunkt der Zeit programmierte und vor allem auch eine gute dokumentierte Software abliefern zu wollen.

Innerhalb des Projektes, häufig durch zu geringer Einbindung des Kunden in den Entwicklungs-, Review- und Feedbackprozess, gerät dann das Projekt in Verzug und entweder der Projektleiter und/oder der Kunde machen Druck, dass man doch nun endlich die Website bzw. Shop fertig werden sollen. Leider vergessen dabei alle Projektbeteiligten, dass mit zunehmenden Funktionen auch die Komplexität der gesamten Software steigt.

Kurz um – es werden aufgrund des gestiegenen Termindruck immer mehr und mehr Funktionen hinzugefügt. Mit sogenannten Hotfixes versucht man auftretende Fehler im Zaum zu halten. Das Testing wird eventuell nur noch auf dem für den Entwickler gängigsten Browser betrieben und die Dokumentation des Projektes kommt gar ganz zu erliegen. Gab es am Anfang des Projektes eventuell noch Coding Guidelines, werden die gerne einmal im Laufe des Projektes vergessen – nur um vermeintlich „schneller“ zu sein.

Alles getreu dem Motto: „Ich baue nur mal eben ’nen Hotfix ein. Morgen mache ich das dann nochmal richtig.„. Inzwischen ist dies wohl in der Software Entwicklung zum Running Gag geworden, auf den manch anderer Entwickler gerne einmal ein „Ja klar, genau dann wenn wir die Dokumentation machen.“ antwortet.

Kurzum, wenn man sich direkt und dauerhaft nicht um Software Qualität kümmert, schleichen sich besagte technische Schulden ein, die am Langen Ende eine Website oder Shop nahezu unwartbar machen. Nicht selten kommt es dann zum Refactoring oder Rewrite, der unnötig mehr Zeit und Kosten verursacht, als wenn man direkt Wert auf Qualität gelegt hätte.

Ab und an wird dies aber auch durch den $Kunden verursacht, der beispielsweise wichtige Updates nicht machen lässt und/oder statt dessen lieber hunderte oder gar tausende Euros in Adwords Kampagnen versenkt.  Im worst-case ist dann ein Agenturwechsel fällig, in der Hoffnung das nun alles besser wird.

Exzellente Software – ohne technische Schulden?

Bereits zu Beginn eines Projektes sollten sich alle Projektbeteiligten, inkl. aller Entwickler, Projektleiter und Kunde, darauf verständigen, dass die Software Qualität die oberste Prämisse ist. Statt immer mehr und mehr neue Funktionen der Website oder dem Online Shop hinzu zu fügen, sollte man lieber frühzeitig die Software, in Absprache mit dem Kunden, veröffentlichen – immer mit Blick auf die Einhaltung aller Qualitätsmaßgaben.

Anhand der Marktreaktionen kann man dann Anpassungen vornehmen und immer wieder die Bedürfnisse des Kunden und des Marktes auf die Software abstimmen. Ein permanenter und offener Austausch aller Beteiligten, zu der Software und zu den Prozessen, ist dabei Pflicht.

Beherzigen alle Beteiligten diese Prämisse, kann man auch mit steigender Komplexität Software ohne oder mit nur wenigen technischen Schulden entwickeln, die am langen Ende für den Projektinhaber $Kunde günstiger ist.

 

Keine technischen Schulden

Keine technischen Schulden

Adhoc und dauerhafte Prüfung der Code Qualität

Im Rahmen der Umsetzung von Websites und Online Shops bedienen wir uns, in unserer Magento und TYPO3 Agentur web-vision, einer entsprechenden Software. Die Open Source Software Sonarqube basiert auf der Programmiersprache Java und besteht im Wesentlichen aus zwei Komponenten:

Der Sonarqube Server ist für  der für die Analyse und Visualisierung der Daten zuständig. Dabei ermöglicht er auf Basis von unterschiedlichen Code Qualitätsprofilen die Möglichkeit zu Analyse einer Vielzahl von Programmiersprachen auch Abseits von reinen Web Entwicklungssprachen. Bereits „out-of-the-box“ bietet Sonarqube Richtlinien für die Analyse der Web Programmiersprachen PHP (PSR2 Standard), JavaScript, HTML und CSS. Darüber hinaus hat man noch die Möglichkeit mit eigenen Regeln die eigenen Coding Guidelines zu prüfen.

Der Sonar Runner nimmt den eigentliche Scan der Software vor. In einer einfache Konfigurationsdatei definiert man nur den Server und schließt Verzeichnisse von Scan ein oder aus. Sobald der Sonar Runner gestartet wurde, speichert er die gefundenen Daten in der entsprechenden Umgebung, zum Beispiel einem Webspaces (DocumentRoot), ab und überträgt diese letztendlich an den Server.

Ein erster Blick auf Sonarqube

Unter http://nemo.sonarqube.org zeigen die Entwickler von Sonarqube eine Demonstration der Möglichkeiten ihrer Software. Für aktuell 260 Open Source Projekte wird hier die Code Qualität auf Basis öffentlich zugänglicher Entwicklungsverzeichnisse, meist GitHub Repositories, vollautomatisch überprüft und auch technischen Schulden in Form von Prozent- und absoluten Zeitwerten ausgewiesen.

nemo.sonarqube.org

nemo.sonarqube.org

Im Segment der Content Management Systeme findet man hier neben Drupal auch das TYPO3 CMS, welches aktuell in seiner 7 LTS Version erschienen ist.

Technische Schulden – Was heißt das konkret?

Die von Sonarqube ausgewiesenen technischen Schulden werden auf Basis der notwendigen Zeit (absolut) und prozentual im Verhältnis zu der Anzahl an Codezeilen gemessen und ausgewiesen. Darüber hinaus wird noch ein genereller Indikator für das gesamte Projekt nach SQALE (Software Quality Assessment based on Lifecycle Expectations)  ausgewiesen.

Ein Bespiel für 5 Minuten technische Schulden:

In der PHP Programmierung kann man für die Programmierung logischer Operationen wahlweise or oder || verwenden. Da dieses or jedoch einen niedereren Rang in der Programmierfolge als andere Operatoren hat, kann die bei der Nutzung zu ungewünschten Ergebnissen führen.

Wenn man um dieses Problem weiß, kann man dies direkt bei der Programmierung berücksichtigen. Hat man jedoch bereits in der entwickelten Software dieses or genutzt, weisst Sonarqube für die Behebung dieses kleinen Fehlers 5 Minuten technische Schulden aus. Das ist die Zeit wo der Entwickler in die Datei gehen muss, den Fehler lokalisiert, die Datei speichert und letztendlich seine Arbeit mit einem entsprechenden Commit abschließt.

5 Minuten technische Schulden

5 Minuten technische Schulden

Die Chance in 5 Minuten TYPO3 Core Entwickler zu werden

Genau das zuvor geschilderte Beispiel ist auch im TYPO3 Core zu finden. Möchte man nun mit ein wenig zeitlichen Aufwand zum erlesenen Kreis der TYPO3 Core Entwickler gehören, kann man diese Fehler – in Abstimmung mit dem Core Team – beheben. Zeitgleich kann man dadurch die ohnehin eh schon sehr gute Code Qualität von TYPO3 noch weiter verbessern.

Aktuell weißt Sonarqube für den TYPO3 Kern 2,4% technische Schulden auf. Im Vergleich dazu liegt Drupal bei 3,3%.

Sonarqube im Agenturbetrieb bei web-vision

Seit einigen Monaten nutzen wir für die Entwicklung von Websites und Shops nahezu den kompletten Atlassian Stack. JIRA als Projektmanagement, Confluence zur Dokumentation, Bitbucket Server (vormals Stash) zur Überwachung und Kontrolle der Versions Kontrolle Git und für die Code Review im Rahmen von Pull Requests, Bamboo für die Durchführung von automatisierten Tests und letztendliche für die Veröffentlichung von neuen Entwicklungen.

Im Rahmen der Einbindung von Sonarqube haben wir zuerst den Sonarqube Server aufgesetzt, der innerhalb des selben Server wie die Atlassian Produkte, seinen Dienst verrichtet.

Für Bamboo haben wir das kostenlos erhältliche Plugin für Sonarqube  integriert. Dieses Plugin nimmt die Integration und Konfiguration für den Prüfungs- und / oder Veröffentlichungsplan vor. Dabei kann man bei Bedarf sowohl das ganze Projekt, als auch nur Entwicklungsfragmente durch Sonarqube scannen lassen und Qualitätsrichtlinien je nach Plan hinterlegen. So kann man zum Beispiel einfach festlegen, dass es mit jeder Entwicklung zu keiner Steigerung der technischen Schulden kommen darf. Oder man kann bestimmte prozentuale Schwellenwerte für technische Schulden hinterlegen.

Für Bitbucket Server gibt es, passend zu dem Plugin für den Bamboo, ein weiteres Plugin. Hat man dieses Plugin erfolgreich installiert und konfiguriert, können so automatisiert die Code Qualität für jeden Pull Request des Entwicklers geprüft werden. Sind technische Schulden vorhanden, werden diese automatisch entsprechend mit Kommentaren und Links versehen. So erhält der Entwickler unmittelbar nach seinem Pull Request automatisch die Erklärung zur Lösung einer technischen Schuld und Verlinkung hinunter zu den betroffenen Codezeilen.

Fazit

Durch diese automatisierte Prüfungen können die Qualitätsrichtlinien für einzelne Projekte und sogar für die ganze Agentur umgesetzt werden. Neue Teammitglieder erhalten so wertvolle Tipps zur Einhaltung der Coding Guidelines und verbessern so dauerhaft Ihre Qualität als Entwickler.

Abschließend nach den automatisierten Tests können dann noch Pull Request durch weitere Teammitarbeiter im Mehraugenprinzip geprüft und letztendlich freigegeben werden.