Wie Sie erstklassige Code-Qualität gewährleisten können

Tatsächlich schadet Ihnen schlechter Code von der ersten Minute an in jeder Phase Ihres Projekts. Er stellt z. B. neue Entwickler bereits während der Einarbeitung vor Probleme und kann dazu führen, dass eines Ihrer Teams möglicherweise nicht in der Lage ist, eine geschäftskritisches Feature rechtzeitig zu liefern. Und sobald ein Unternehmen in einem hohen Maß unter technischen Schulden leidet, sind alle Abteilungen in ihrer Arbeitsfähigkeit eingeschränkt.

“It’s not enough for code to work” – Robert C. Martin

Was ist schlechter Code?

Als Ausgangspunkt für die Definition dieses komplexen Begriffs könnten wir beim Schlagwort Softwarequalität beginnen wobei hier das Grundprinzip herrscht, dass letztendlich die Bedürfnisse und die Zufriedenheit der Nutzer ausschlaggebend sind. Die Definitionen von Code-Qualität und Softwarequalität sind sich sehr ähnlich, man darf dabei jedoch nicht vergessen, dass alle an der Entwicklung des Projekts beteiligten Ingenieure ebenfalls zu dieser Nutzergruppe gehören, da sie im Entwicklungszeitraum natürlich ebenfalls Nutzer sind.

Fazit: Qualitativ hochwertiger Code sorgt sowohl für zufriedene Endnutzer als auch für zufriedene Ingenieure. Der Fokus auf hochwertigen Code trägt positiv zu einer breiteren Geschäftsausrichtung und einem besseren Ressourcen-Management bei: Er garantiert einen leichteren Projekteinstieg und schnellere Fortschritte, kürzere Feature-to-Market-Zeiten, eine verbesserte Fehlervermeidung, reduzierte Codeüberprüfungszeiten, eine natürliche Wissensverbreitung und verleiht kleineren Teams die Fähigkeit, parallel zu arbeiten, was bedeutet, dass es keine Engpässe gibt, weil sich nur bestimmte Experten im „Minenfeld“ von schlechtem Code auskennen.

Welche Auswirkungen hat schlechter Code im Vergleich zu qualitativ hochwertigem Code? Die langwierige Entwicklung neuer Features folgt auf Basis von schlechtem Code einer schwer verständlichen Geschäftslogik. Ein fehleranfälliges System kann hohe „technische Schulden“ verursachen. Und mit der Zeit beginnt schlechter Code zum Himmel zu stinken. Jeder leitende Softwareentwickler kann Ihnen genau sagen, wann ein Pull-Request minderwertigen Code enthält.

Meistens kommt es dabei zu folgender Situation:

Code ist jedoch meistens nicht von Anfang an bereits schlecht. Häufig ist Code zu Beginn sogar qualitativ hochwertig, wobei die Qualität mit der Zeit rapide abfällt, zumeist zwischen verschiedenen SOLID-Releases.

Unser Job ist es, sicherzustellen, dass wir uns eng an die graue Linie in der Abbildung halten.

Auf der Suche nach dem Allheilmittel

Spoilerwarnung: Ein Allheilmittel existiert nicht, es gibt jedoch eine hervorragende Alternative: eine gute Strukturierung Ihrer Prozesse.

Hier stellen wir Ihnen einige Praktiken vor, die wir bei Spryker verwenden, um Code-Qualität zu definieren, zu messen und im Laufe der Zeit stetig zu verbessern. Sie werden wahrscheinlich nicht Gefallen an all diesen Praktiken finden und einige der Maßnahmen werden für Sie zu komplex oder zeitaufwendig sein. Eine Sache, die Sie jedoch unbedingt tun müssen, ist eine Grenze zu definieren, die Sie niemals überschreiten werden. Sobald Sie diese definiert haben, werden sich Ihr Prozess und Ihre Tools langsam daran anpassen.

Professional sein heißt professionell wachsen

In unserem Unternehmen halten wir uns streng an die SOLID-Prinzipien und das Konzept des „Clean Codes“. Die meisten unserer Entscheidungen beruhen auf diesen Säulen. Wenn Sie mit diesen zwei Prinzipien oder gängigen Begriffen wie KISS, DRY und YAGNI noch nicht vertraut sind, sollten Sie sich unbedingt mit Ihnen vertraut machen. Natürlich kann man immer über das „Wann“ und „Wie weit gehen wir“ diskutieren, aber im Allgemeinen bieten diese Prinzipien Ihnen eine gute Grundlage.

Wie Sie Ihre Abhängigkeiten in den Griff bekommen

Zuallererst müssen Sie Ihre Abhängigkeiten definieren. In unserem Fall ist das auf den ersten Blick einfach, dabei enthält jedes Modul bereits Abhängigkeiten, die sehr komplex sind. Es wird noch komplizierter, wenn man bedenkt, dass wir uns als Softwareanbieter dazu verpflichtet haben, eine saubere, modulare Architektur bereitzustellen, die zum heutigen Zeitpunkt bereits mehr als 300 Module enthält.

In Ihrem Fall können natürlich andere Abhängigkeiten eine Rolle spielen: vielleicht gibt es bei Ihnen Abhängigkeiten von einem Service oder einem Microservice, einem Modul oder einem Paket, einer Anwendung oder einer Domain. Eine klare Definition Ihrer Abhängigkeiten ermöglicht es Ihnen, Beziehungen zwischen diesen Abhängigkeiten zu definieren.

Sobald Sie Ihre Abhängigkeiten und deren Beziehungen untereinander definiert haben, sollten Sie dafür sorgen, dass diese so übersichtlich und aufgeräumt wie möglich bleiben. Je weniger Abhängigkeiten Sie haben und je weniger diese untereinander gekoppelt sind, desto weniger kaskadierende Probleme müssen Sie lösen.

Wenn Sie sich ein wenig vertiefen wollen, empfehlen wir Ihnen, sich etwas umfassender mit den folgenden Themen zu befassen:

Metriken für Softwarepakete: Afferente Kopplung, efferente Kopplung, Abstraktheit und Instabilität. Mehr dazu finden Sie in dem Buch „Agile Software Development: Principles, Patterns and Practices.“ von Robert C. Martin.

Anschließend können Sie sich mit Begriffen wie „Kopplung“ (Software Engineering — Guide to the Software Engineering Body of Knowledge) und „Abhängigkeitshölle“ (englisch: Dependency Hell, vor allem relevant bei der Verwendung von Micorservice-Architekturstilen) beschäftigen.

Messungen helfen, Ihre Code-Qualität aufrechtzuerhalten

Nehmen Sie von Anfang an Messungen vor. Es gibt Unmengen an Tools, die Ihnen dabei helfen können, z. B. Scrutinizer, Codacy, Blackfire, Travis CI oder andere CI-Tools. Für PHP gibt es folgende Tools: PHP Mess Detector, PHP Stan, PHP_CodeSniffer und noch viele weitere IDE-Plugins. Sie werden natürlich nicht alle auf einmal brauchen. Wählen Sie einfach die Tools aus, die Ihren Anforderungen gerecht werden.

Legen Sie Schwellenwerte fest und integrieren Sie diese in Ihren Prozess. Bei Spryker erzielen wir mit all unseren ~300 Modulen einen Scrutinizer-Wert von 9,62 Punkten. Wir haben uns außerdem darauf geeinigt, diesen Wert für alle Feature-Releases einzuhalten und ihn im Rahmen von Cleanups und Major Releases weiter zu erhöhen.

Es dreht sich alles um Teamwork

Wir alle wissen bereits, wie wichtig es ist, Kodierungsprinzipien auf persönlicher Ebene zu verstehen. Wenn es jedoch um Kommunikation und Zusammenarbeit geht, gibt es noch eine Vielzahl weiterer Herausforderungen. In der Regel hat jeder Mitarbeiter seine eigene, begründete Meinung und will sein Projekt verbessern. Deshalb haben wir bei uns einen robusten Prozess in Bezug auf Änderungsvorschläge eingeführt: Zuerst definiert ein Mitarbeiter ein Problem in einem RFC-Dokument, anschließend schlägt er mithilfe eines Schemas eine Lösung vor, erstellt danach ein “Proof of Concept” bzw. schreibt Beispiel-Code und präsentiert schlussendlich dem gesamten Team seinen Standpunkt. Falls der Vorschlag akzeptiert wird, werden die Änderungen sofort umgesetzt.

Wenn Sie keinen Prozess für Änderungsvorschläge definiert haben sollten, stehen Ihnen nur begrenzte Möglichkeiten zur Verfügung, um offensichtliche Probleme zu beheben und Entscheidungen auf der Grundlage realer Vorschläge und nicht auf der Grundlage einzelner Meinungen zu treffen.

Lassen Sie Ihren Code für sich sprechen

Jedes Team verfügt über eine eigene Kultur und einen eigenen Coding-Stil. Für ein Entwicklungsteam ist es überaus wichtig, einen gemeinsamen Coding-Stil zu finden und diesen zu dokumentieren. Ein solches Dokument zu haben, auf das Sie verweisen können, spart Ihnen viel Zeit und vermeidet unnötige Diskussionen. Größere Änderungsvorschläge sollten den RFC-Prozess durchlaufen.

Nicht alles sollte jedoch vordefiniert werden. Die Versuchung ist groß, alles in einem gemeinsamen Team-Dokument, z.B. auf einer Wiki-Seite, zu dokumentieren. In der Praxis gilt: Je größer ein Dokument, desto schneller veraltet es. Und es wird immer Themen geben, die zwischen den dokumentierten Konzepten angesiedelt sind und diskutiert werden müssen. Halten Sie Ihre Code-Basis sauber und auf dem neuesten Stand und verwenden Sie sie, um Beispiele zu erläutern und neue Entwickler einzuarbeiten. Ihr Code sollte für sich sprechen können, ohne unbedingt Ihre Dokumentation hinzuziehen zu müssen.