In letzter Zeit habe ich mich viel mit Testing und Softwarequalität beschäftigt. Da ich von diesen Themen und Tools überzeugt bin, habe ich sie bedenkenlos eingesetzt. Im Geschäft habe ich auch Jenkins aufgesetzt und betrieben.

Überzeugungsarbeit für den Codesniffer

Ich versuchte stets die Leute in den Projekten davon zu überzeugen, dass sie phpcs (PHP Codesniffer) auf der Konsole vor dem einchecken durchlaufen lassen sollten und dann entsprechend den Fehlern die Korrekturen durchführen sollten. Als sie meine Anweisung mit einem “WARUM?” erwiderten, antwortete ich jeweils, dass der Code so halt einheitlicher und aufgeräumter wirkt.

Warum überhaupt einen Codesniffer verwenden?

Auf einmal fragte ich mich selber, warum man einen Codesniffer einsetzen sollte. Bringt es dem Kunden einen Nutzen, wenn der Code dahinter “schön” und einheitlich aussieht? Ich versuchte also herauszufinden, warum es Sinn ergibt, wenn man sich Standards bei der Formatierung hält.

Ich forschte also ein bisschen nach und bin auf zwei gute Erklärungen gestossen.

Keine Unterbrechung des Flows

Es ist allseits bekannt, dass etwas neues, unerwartetes viel mehr Energie kostet. Genauso ist es bei einem Codestyle, der die ganze Zeit wechselt. Man benötigt neben dem Lösen des Problems noch viel Energie, die verschiedenen Codestyles mental aufzuarbeiten.

Wenn man einen bestimmen Codestyle kennt, kann man sich auf die wahren Probleme konzentrieren. Die Klammern, Einrückungen usw. verschwinden und man konzentriert sich auf die Aufgabe.

Je weniger der Entwickler oder Reviewer gestört wird, desto schneller ist er mit seiner Arbeit fertig. Dies hat also einen positiven Nutzen für den Kunden.

Keine Diskussionen mehr über den Codestyle

Wenn man sich auf einen Standard einigt (z.B. Symfony2, PEAR, Zend, …), so müssen sich die Entwickler nicht mehr darüber streiten, wie Code formatiert werden soll. Dies bringt dem Kunden einen unmittelbaren nutzen, nämlich keine verschwendete Zeit mit Diskussionen über den Codestyle.

Feedback

Was haltet ihr vom Einsatz eines Codesniffers?

Warum sollte man ihn einsetzen oder warum gerade nicht?

Ich würde mich über Feedback freuen!

Die Softwareentwicklungsbranche ist noch zu wenig professionell

Einige Personen und Firmen mögen zwar professionell sein, aber sicher nicht die grosse Masse.
Gemäss Clean Code Developer bedeutet

Professionalität = Bewusstheit + Prinzipien

Es muss ein Bewusstsein und ein Wille vorhanden sein, sauberen “schönen” Code aufgrund von Prinzipien zu erstellen. Es muss einem Bewusst sein, was passiert, wenn man sich nicht an die Prinzipien hält und jeder gerade so entwickelt, wie es ihm passt.

Es ist auch mit schlechter Software möglich Geld zu verdienen

Und das nicht mal wenig. Wenn man eine schlechte Applikation ausliefert, welche viele Fehler hat, kann man auch häufig viel Geld für Korrekturen und Erweiterungen verlangen. Somit ermöglicht dies auch eher unprofessionellen Firmen sehr viel Geld zu verdienen und so weiter zu fahren wie bisher.

Kunden haben zu wenig Erfahrung mit Software

Es ist klar das es für viele Kunden schwierig einzuschätzen ist, ob ein Produkt / eine Firma professionell ist. Häufig bindet sich ein Kunde mit hohen Investitionen an ein Produkt / eine Firma. Die nachfolgenden teuren Korrekturen und Erweiterungen sind immer noch günstiger, wie ein Wechsel auf ein anderes Produkt. Daher fährt man mit dem gleichen Kurs weiter. Erst wenn eine hohe Schmerzgrenze erreicht ist, kann sich der Kunde für einen Wechsel entscheiden.

Die Branche entwickelt sich sehr schnell weiter

Was gestern noch richtig war, kann heute schon veraltet sein. Schlechter Code der vor 10 Jahren geschrieben wurde, ist heute immer noch schlecht. Aber Methodiken haben sich mit der Zeit verändert. Softwaredesigns, welche vor 10 Jahren ein absoluter Hype waren, sind heute schon ein bisschen angestaubt.

Regelsets definieren – der alte Weg

Vor einigen Monaten habe ich den CodeSniffer durch die Artikelserie von Nils auf phphatesme entdeckt. Der CodeSniffer wurde von mir direkt ausprobiert. Kurze Zeit später habe ich eigene Regeln erstellt (Regelset Ordner mit PHP kopieren und anpassen…), was aber eine recht mühsame Angelegenheit ist. Zum Glück gibt es jetzt eine neue Möglichkeit…

Regelsets definieren  - neu mit XML

Ab der Version 1.3.0 kann man die Regeln sehr einfach mit einem XML File konfigurieren. Hier ein Beispiel:

Das XML sagt folgendes:

• Nimm alle PEAR Sniff Regeln
• Schliesse von PEAR die Regeln LineLength und ScopeIndent aus
• Ergänze eine einzelne Regel OpeningFunctionBraceKernighanRitchie

Somit hat man (wenn man die Regeln mit Namen kennt) innerhalb von wenigen Minuten seine eigenes Ruleset zusammengestellt. Weitere Tips gibts bei Squizlabs nachzulesen.

Anwendung Regelset

Möglichkeit 1

Das Regelset kann ich nun im Standards Ordner von Codesniffer ablegen (unter Ubuntu /usr/share/php/PHP/CodeSniffer/Standards/<RegelsetName>/ruleset.xml).

Danach einfach folgenden Aufruf machen:

phpcs –standard=<RegelsetName> /path/to/code

Möglichkeit 2

Das XML kann irgendwo abgelegt werden und muss dann so aufgerufen werden:

phpcs –standard=/path/to/ruleset.xml /path/to/code

Schlüsselfaktoren für eine langfristig gute und qualitativ hochwertige Software sind:

• Kommunikation zwischen den beteiligten Personen (Projektleiter, Entwickler, Kunde)
• Automatisierung wo es nur geht -> Continuous integration
• Stimmung / Motivation im Team -> Der Wille sich ständig verbessern zu wollen
• Abdeckung der Software durch Tests -> Unit Tests, Integration Tests, …
• Kontinuierliches Refactoring -> Die Software ändert sich schliesslich immer
• Regelmässige Code Reviews
• Modularer und unabhängiger Aufbau der Softwarekomponenten

Es ist zwar etwas zusammengewürfelt, aber ich möchte einfach noch ein paar Gedanken zu den oben aufgezählten Punkten erwähnen.

Wenn das Programm läuft ist man nur halb fertig

Wenn man glaubt, das man mit einer Funktion fertig ist, hat man normalerweise etwa die hälfte geschafft (ausser man entwickelt mit TDD, da ist’s besser)Wenn bei uns die Lehrlinge jeweils sagen, dass sie fertig sind, frage ich sie:

• Ist der Code dokumentiert?
• Ist der Code mit Tests abgedeckt?
• Hat jemand ein Review von deinem Code gemacht?
• Hast du den Code schon refaktorisiert bzw. aufgeräumt?
• Läuft es auch auf einer anderen Installation?

Natürlich ist die Antwort eigentlich immer nein (wahrscheinlich wie bei den meisten Entwicklern). Man sollte sich also auch unter Zeitdruck immer fragen, ob die Aufgabe auch wirklich erledigt ist. Niemals sollte man sich damit zufrieden geben, dass es einfach nur läuft, auch wenn einem dies jemand anders so vermitteln will.

Modularer Aufbau von Software

Inzwischen bin ich der festen Überzeugung, dass Software modular aufgebaut und in kleine Teile unterteilt sein sollte. Viele kleine Legosteine, welche keine Abhängigkeiten haben, sind viel einfacher zu einem ganzen zusammenzufügen, also grosse und undurchschaubare Konstrukte. Zwei wichtige Prinzipien sind hier Separation of Concern und Dependency Inversion Principle.

Testen

Immer wieder höre ich, dass z.B. Unit Testing nur Zeit benötigt und eigentlich gar nicht soviel bringt. Diesem Punkte kann ich absolut nicht zustimmen. Testing ist etwas absolut essentielles.

Schreibe ich Tests, formuliere ich meine Anforderungen an die Funktion. Ausserdem stelle ich sicher, dass meine Architektur im kleinen gut ist (bei zu vielen Abhängigkeiten wird es schwierig überhaupt zu testen). Zudem muss ich keine Angst vor Refactorings haben. Aussagen wie diese gibt es nicht mehr: “Ich mach mal lieber nichts an dieser Funktion, ich weiss ja nicht, ob sie nachher noch funktioniert”.

Refactoring

Refactoring ist immer wieder nötig, da sich die Software auch ständig ändert. Wer kein Refactoring macht, sondern alles an das Bestehende anhängt, wird über kurz oder lang einen riesen Krüppel generieren.

Code Reviews

Code Reviews haben mehrere Vorteile. Man kann mit anderen kommunizieren und so auch seinen Horizont erweitern. Ausserdem sieht jemand anders häufig Fehler oder unklare Konstrukte, die einem so nie aufgefallen wären.

Zusammenhang zwischen Code Reviews, Modularität, Testing und Refactoring

Die Zusammenhänge ergeben sich eigentlich von alleine. Um gute Software, sprich unabhängige, modulare Software zu produzieren, muss man sie mit Tests abdecken. Da sich Software ständig ändert, muss sie Refaktorisiert werden, ohne Tests ist dies nicht ohne Fehler möglich. Die Code Reviews unterstützen diesen Prozess.

Da ich mich momentan sehr für Qualität in der Softwareentwicklung interessiere, darf das Unit Testing natürlich nicht fehlen. Mit PHPUnit konnte ich nun schon einige sehr positive Erfahrungen machen. Da auch viele PHP Projekte mit Javascript arbeiten, suchte ich deshalb auch nach einen Testwerkezeug für JS.
Auf der Webseite Test Driven Websites bin ich auf einen schönen Javascript Unit Testing Framework Vergleich gestossen. Der Favorit war ganz klar JsTestDriver und nach einigem weiteren Surfen im Netz, hat sich für mich dieser Eindruck bestätigt. Da es sehr viele Test Frameworks für Javascript gibt, habe ich den allgemeinen Eindrücken im Netz einfach vertraut und mich für JsTestDriver entschieden.

Highlights von JsTestDriver

• xUnit konformer Syntax (sprich, der Syntax lehnt sich an PHPUnit oder Junit an)
• Die Tests benötigen kein HTML File, wie in anderen JS Testframeworks
• Client/Server Architektur für Tests (Das Prinzip ist ähnlich wie bei Selenium) -> Der Test-Server muss somit nicht lokal laufen
• Durch die Client/Server Architektur können mehrere Browser gleichzeitig getestet werden
• Plugin für Eclipse und IntelliJ IDEA – bei jedem Save werden die Tests automatisch durchgeführt
• Plugin Architektur – JsTestDriver bietet Plugins um andere Unit Testing Frameworks oder auch Mocking Frameworks zu integrieren
• Problemlos in Continuous Integration Prozess integrierbar

Stolpersteine

• JsTestDriver besitzt keine Möglichkeit zu mocken (ok, alle anderen JS Frameworks auch nicht). Es kann aber problemlos ein Mocking Framework eingebunden werden
• Achtung bei globalen Variablen/Funktionen/Objekte – werden die globalen Variablen beim Testdurchlauf überschrieben, haben sie beim nächsten Durchlauf immer noch den überschriebenen Wert. Dies gilt so lange, bis entweder der Server neu gestartet wird, oder das Source File, wo die Variable deklariert wurde verändert wird. Der Grund ist Performance: Der Server cacht alle .js Dateien und lädt sie nur neu, wenn eine Datei auch verändert wurde.

Installation

Auf der JsTestDriver Homepage, wird sehr einfach beschrieben, wie man das Framework installieren und konfigurieren kann.
Auf der Homepage von James Carr erfährt man weitere nette Details über JsTestDriver.

Code Example

TestCase("MyTestCase", {
    setUp: function() {
        //...
    },

    testAssertionWithMessage: function() {
        assertTrue("this is not true", false);
    },

    testAssertionWithoutMessage: function() {
        var actual = 5;
        assertEqual(5, actual);
    },

    tearDown: function() {
        //...
    }
};

Fazit

JsTestDriver ist für mich absolut empfehlenswert. Ich konnte mich dank den PHPUnit Kenntnissen sehr rasch im Framework zurechtfinden und hatte schon nach kurzer Zeit die ersten Tests geschrieben. Die grössten Vorteile sind für mich: CI, erweiterbar mit anderen Frameworks, Multibrowsertesting