Schon seit längerem denke ich über ein Thema für einen neuen Blogeintrag zum Thema Softwarequalität nach. Schlussendlich fiel mir der folgende Kommentar zum Thema “Wie schreibt man guten Code?” in’s Auge, welcher mich dazu brachte, mir ein paar Gedanken über guten Code (vor allem im Team) zu machen. Eins vorweg: dieser Artikel ist gerade in der Entstehungsphase – und wird noch das eine oder andere Update erhalten. Er soll für mich eine Art “Leitfaden” darstellen, in welchem ich meine neuesten Erfahrungen und Best-Practices einfließen lasse.

Dadurch, dass das Thema Softwarequalität auch eine starke Verknüpfung mit strukturiertem, gut wartbarem Code eingeht, spielt dieses Thema eine große Rolle – gerade im Umgang mit der Scriptsprache PHP.
An vielen Stellen in den PHP-Projekten meines aktuellen Arbeitgebers werden sogar in den Controllerklassen und den darin enthaltenen Action-Methoden (wir setzen auf das Zend-Framework) diverse Abfragen und Konstrukte eingebunden, welche sich in einem eigens erstelltem Model-Objekt genauso lösen ließen. Auch werden viele Controller mit verschiedenen Methoden überladen, welche ebenso in andere Controller-Dateien ausgelagert werden könnten.

Doch wie genau bringe ich mein Team dazu, einen hochwertigen und strukturieren PHP-Quelltext zu schreiben?

Ich selbst habe mir diese Frage in den letzten Tagen sehr oft gestellt – zum einen, um meine eigenen Quelltexte zu optimieren, zum anderen sollen auch Neueinsteiger einen schnelleren Überblick über das Projekt erhalten.

Besonders wichtig ist es in meinen Augen, dass der gesamte Quelltext homogen wirkt – das heißt, dass die einzelnen Bestandteile (Models, Logikklassen, Controller) über ähnliche Strukturen verfügen. Implementiere ich beispielsweise Controller, welche Hotelbuchungen und Flugbuchungen durchführen, so sollten diese über einen ähnlichen Codestil verfügen. Actionnamen und Methodennamen sollte man nach dem gleichen Muster aufbauen, sodass das Wissen von Controller A zu Controller B einfacher übertragen werden kann. Natürlich sollte man, wo immer es geht, Redundanzen vermeiden um einen einfach wartbaren Quellcode zu haben.

Der zweite Punkt ist meiner Meinung nach besonders beim Arbeiten im Team wichtig: legt (sofern noch nicht vorhanden und lohnenswert) Helper-Klassen und -Methoden an. Gerade dann, wenn vorhersehbar ist, dass dieser Helper früher oder später neue Methoden hinzugewinnen wird. Meiner Erfahrung nach hilft das auch anderen Teammitgliedern, ihre eigenen Helper-Methoden in diese Klasse zu stecken, statt sie irgendwo im Controller oder einem Model zu verstecken. Was einmal da ist, wird benutzt – muss man jedoch selbst diese Klasse anlegen, überlegt man es sich dann doch noch einmal und lagert das Ganze in ein Model oder im Controller ein.

Ganz besonders wichtig: hinterfragt das, was ihr tut! Einige Beispielfragen hierfür wären:

• Ist der Quelltext testbar?
• Können andere ihn lesen und verstehen, oder muss ich einige Lösungen doch lieber in eine extra Methode auslagern und besser kommentieren?
• Kann ich das gleiche auch an anderen Stellen noch einmal verwenden? Wenn ja: Habe ich es in eine extra Helfer-Klasse ausgelagert?
• Sind die Bindungen an andere Klassen/Objekte sinnvoll, oder kann ich den Quelltext mit Hilfe verschiedener Pattern (Dependency-Injection o.ä.) flexibler gestalten?
• Habe ich ausreichend Dokumentiert? (Trac-Einträge, PHPDoc und Co.)

Sehr häufig fällt auf, dass Entwickler zu wenig dokumentieren. Wenn ihr neue Objekte erschafft – dokumentiert sie! Schreibt auf, was sie machen, wofür sie zu gebrauchen sind und welchen Daten in welcher Struktur enthalten sind. Das hilft Neueinsteigern ungemein, sich in die Tiefen der (oftmals seit Jahren historisch gewachsenen) Quelltexte einzuarbeiten und diese zu verstehen. Anderenfalls (und damit müsst ihr rechnen) benötigen diese weit mehr Zeit, als zur Verfügung steht – oder extrahieren sich das Wissen aus euren Köpfen, was zu Lasten eurer Arbeitszeit geht. Damit sind wir auch schon bei einem der wichtigsten Punkte überhaupt in der modernen Softwareentwicklung: Dokumentation. Gerade moderne Entwicklungsverfahren bieten gute Möglichkeiten zur Softwaredokumentation. Die Continuous Integration (oder auch SCRUM) arbeiten in vielen kleinen Iterationen. Ist eine Iteration geschafft, kann der aktuelle Entwicklungsstand dokumentiert werden. Im Gegensatz zu älteren Entwicklungsverfahren (z.B. dem Wasserfallmodell) ist das ein wahrer Segen.

Habt ihr eigene Ideen, wie man guten und strukturierten Quelltext schreiben kann? Die Kommentare gehören euch…