Effektives Webdevelopment Clean Code

Wenn man als Webdeveloper schneller und effektiver arbeiten möchte muß man sich viel gezielt in dem Bereich der Programmierer-Produktivität schulen. Und wie immer muß man auch das Ziel und den Nutzen dieses Aufwands sehen, damit man den Weg geht. In der heutigen Zeit werden Webprojekte grundsätzlich wesentlich anspruchsvoller und haben viele Feature Releases. In diesem Zusammenhang spricht man häufig von agiler Softwareentwicklung. Hier ist es ein langer Weg und stetiger Entwicklungsprozess. In einer Artikelreihe hatte ich ja schon ausgiebig die Produktivitätskiller für Programmierer vorgestellt und befasse mich in diesem und kommenden mit dem Thema „Effektives Webdevelopment Clean Code“.

Effektives Webdevelopment Clean Code Regeln

Robert C. Martin hat mit seiner Buch Clean Code einen Meilenstein der agilen Softwareentwicklung veröffentlich und das schon vor Jahren getan. Das ganze Buch kann ich hier jetzt leider nicht wieder geben und ich habe aber schon ein paar Kapitel darüber verfasst. Webdevelopment: Clean Code Regeln – Smells und Heuristiken ist ein Blog-Post von mit, der sich explizit mit Code Smells beschäftigt. Nachfolgend kommen nun ein paar kleine Erläuterungen, die in ähnlichen Kontext stehen.

Die richtige Technologie ist keine Lösung

Viele Wege führen nach Rom und viele Webtechnologien können gleiche Projektansprüche realisieren. In der heutigen Zeit greifen Webdeveloper sehr gerne auf fertige Lösungen zurück. Das ist auch gut und berechtigt. Der Anspruch an Webdesign und vor allem Funktionen also Features ist stark gewachsen.  Deshalb braucht man etwas auf das man zurück greifen kann. In dem Bereichen CMS gibt es hier die beiden führenden Open Source Lösungen TYPO3 und WordPress. Aus den Bereichen Reporting und Monitoring tolle NodeJS Applikationen und natürlich die beiden Framework Boliden Zend Framework und Symfony. Das sind sehr große und mächtige PHP-Frameworks, die komplexe und anspruchsvolle Webapplication Projekte abbilden können. Für einfache Unternehmenspräsentationen bietet sich eine CMS Lösung an. Mit den PHP-Frameworks kann man sehr gut spezifische Geschäftsprozesse als Softwarelösung anbieten und entwickeln. Aber egal für was man sich an dieser Stelle entscheidet, wichtig ist diese Technologie zu beherrschen und ihre Vorteile und Vorzüge zu nutzen und einzusetzen. Es bringt nichts eine High-Performance-Appication auf NodeJS zu entwickeln und dann alle asynchronen Prozesse auszuhebeln. Die Programmierung und das eigentliche Webdevelopment nimmt einem niemand ab. Es ist besser mit einer Technologie vertraut zu sein und diese seit Jahren zu beherrschen, als einfach auf etwas neues zu setzen. Aber en Blick über den Tellerrand loht und Einstiegstutorials sind ja schnell erledigt. Es ist sicherlich nicht richtig einen „Hammer für jedes Problem“ einzusetzen. Das funktioniert zwar auf Tankschiffen, aber nicht in der Webentwicklung.

Lesbarkeit ist wichtiger als Komplexität

Es gibt Clean Code Regeln die besagen, daß weniger Code weniger Arbeit ist. Effektives Webdevelopment Clean Code hat aber stark etwas mit der Lesbarkeit zu tun. Angeblich lesen Webdeveloper 75% ihrer Zeit Code und müssen sich hierbei immer wieder in die aktuelle Stelle und auch die aktuelle Komplexität einfinden. Lesbarkeit ist dabei entscheidend. Auch hier gibt es keinen heiligen Gral. Ich hatte die Tage eine Anfrage zu einer Methode, die für einen Sprachswitch eine entsprechene URL gibt. Der Kollege wollte translateUrl() haben. Tatsächlich gab die Methode aber für einen URL-Key und einen Language-Code die URL zurück. Daher habe ich die Methode getTranslateUrlByKeyLanguageCode($key, $languageCode) genannt. Das beschreibt exakt, was die Methode genau tut. Man erkennt was man bekommt und was an Parametern erforderlich ist.  Der ursprünglich geforderte Methoden Name sagt das nicht aus. Ohne Parameter würde man bei mehreren Sprachen auch berechtigt fragen, warum das nicht Urls heßt. Da sie aber nicht mal eine getter-Methode ist könnte es sich sogar um eine Handler-Methode halten, mit der man hier gar nichts anfangen kann. Hier sind Code-Reviews völlig entscheidend. Im Team über Namen sprechen und sich auf eine gemeinsame Sprache einigen.

Nur nötigen Code schreiben

Das ist eine wichtige Regel, gerade in der agilen Softwareentwicklung. Einen sehr interessanten Artikel gibt es dazu „The Gas Factory or Unnecessary complexity„. Code darf nicht unnötig Komplex gemacht werden, sondern wächst nur mit seinen Features. Das ist nicht immer einfach. Clean Code soll effektiv sein. Das heißt nicht zwingend, daß er schneller geschrieben ist. Aber da er nach hinten raus weniger Bugs hat und stabiler ist spart man hier Zeit. Auch durch die bessere Lesbarkeit und konsequente Struktur. Aber noch einmal ganz deutlich „Nur nötigen Code schreiben“. Wenn man eine Seite z.B. mehrsprachig anbietet, so kann man sich auch erstmal auf englisch beschränken und muß nicht direkt für alle Sprachen verfügbar sein. Man braucht auch keinen CSV-Translation-Upload Handler, damit man seine Sprachkeys einfach an ein Übersetzungsbüro geben kann. Es ist wichtig früh mit Config-Dateien zu arbeiten und generell alle Variablen, die man manuell befüllt, dorthin auszulagern.

Clean Code Kommentare vermeiden

Kommentare im Quellcode sind falsch. Die Aussage kann man treffen und ja es stimmt. Noch schlimmer sind in meinen Augen @todo Kommentare. Aber grundsätzlich erst einmal zu den Kommentaren. Gut lesbarer Quellcode braucht sie nicht und macht sie durch seine Aussagekräftigen Bezeichnungen überflüssig. Soweit die Lehrbücher, Robert C. Martin und auch persönliche Erfahrungen. Dazu muß gerade dieser Code auch gewartet werden. Am schlimmsten ist auskommentierter Quellcode. Den traut sich so gut wie nie einer wegzuwerfen und er läuft wahrscheinlich eh nicht und spätestens nach ein paar Commits aus dem File.

Code planen und das Ziel kennen

Ein Feature hat klare Ziele und auch Anforderungen. Das wird dann in einem kleinen Software Modell behandelt und umgesetzt. Ob als Bundle, Extension, Erweiterung, Lazy-Load-Middleware oder wie auch immer. Es ist wichtig seine Software zu planen. Welche get- und set-Methoden werden gebraucht. Was für Handler sind für die Application nötig und welche Helper braucht man. Eine weitere Steigerung daraus ist das Test-Driven-Development. Hier werden die Return-Werte einer Methode abgeglichen. In den letzten Jahren gab es immer wiederkehrend große Diskussionen, ob es besser ist Test-Driven-Development zu betreiben. Das will ich hier nicht beantworten. Gute Tests sind ausschlaggebend für nachhaltige Softwareentwicklung. Und natürlich ist es ok, die Tests zu erst zu schreiben.

Erst Tests schreiben, dann zum testen geben

Es ist wichtig seine Applikation mit Tests abzudecken. Nur so kann man sich sicher sein, das wichtige Funktionen so funktionieren und die Ergebnisse liefern, die man möchte. Zudem beleuchtet man seine eigene Programmierung viel kritischer. Welche Parameter gebe ich rein und welche kommen wie raus? Was bringt die Applikation zum Absturz? Wie verhält sich die Methode, wenn Dienste oder Datenbanken nicht erreichbar sind.

Manuelles Testen ist absolut wichtig. Im einer Extremform wird natürlich nach Livegang am User getestet. Hier ist es wichtig, daß Bugs, die hier gefunden werden, schnell in Testszenarien einfließen und abgebildet werden können. Jeder Fehler, der von anderen Leuten als dem Webdevelopment Team gefunden wird stellt eine Belastung dar und wirft ein schlechtes Licht auf das Projekt. Es bieten sich hier DalekJS Tests an, damit Fehler die von Usern oder Testern gefunden wurden schnell abgebildet werden können.

Weiterbildung und Austausch

Es ist wichtig nicht nur alleine zu an der Codefront zu kämpfen. „Never walk alone“. Es gibt sehr gute Usergroups z.B. in Köln, Düsseldorf und Hamburg. Da lernt man von Codern für Codern viele nützliche Tips. Diese mitzunehmen und in seinen täglichen Arbeitsablauf zu integrieren ist ein unglaublicher Faktor, die persönliche Software-Qualität entscheidend zu erhöhen und sich darüber hinaus positiv zu motivieren.

Spaß an der Arbeit haben

Wir arbeiten viel und hart. Und immer gegen die Uhr, gegen Kosten. Hier ist es wichtig motiviert und wach zu bleiben. Code zu refactorisieren und zu reviewen. Es bringt nichts gegen Marketing Windmühlen zu kämpfen, oder sich von anderen Faktoren ins Burnout treiben zu lassen. Das geht schnell und zerstört mehr als nur die Laune. Arbeitet bei Arbeitgebern die gute Entwickler einstellen und euch fördern. Schreib dich nicht ab und nimm ggf. einen neuen Job. Unsere Arbeit macht Spaß und wird auch dankbar behandelt.

Best practices sind Erfahrungswerte mit Austausch

Zu jeder Programmiersprache gibt es best practice Tipps. Diese sind allerdings nie auf den eigenen Case anwendbar. Im Laufe des Lebens als Webentwickler lernt man viele Methoden strukturiert, effektiv und sauber zu arbeiten. Aber das ganze muß man auch mal kritisch anschauen. Pair Programming ist hier sehr gut und bringt immer beide Code sehr viel weiter.