Gedanken zur agilen Softwareentwicklung
Wie man es besser macht
Im ersten Teil zum Thema User Directives wurde erläutert, wie diese in die FreshMarker Engine eingefügt sind und wie eigene Java Directives erstellt werden können. In diesem Teil werden die User Directives um FreshMarker Macros erweitert.
Zu den ersten Komponenten der FreshMarker Template-Engine gehörte ein einfaches Plug-In System. Durch diese Komponente wurde die Ergänzung um neue Built-Ins, Formatter und Mapper vereinfacht. Zwei neue Plug-Ins zeigen dabei Stärken und Schwächen des bisherigen Ansatzes.
Nichts ist ärgerlicher bei der Verbesserung von Legacy Software als die Abhängigkeit von Klassen, die sich modernen Sprach Konstrukten verweigern. Eine besondere Gruppe dabei sind all die Klassen, die sich zieren vom Interface AutoClosable zu erben. Diese Klassen sind durch veraltete Abhängigkeiten in das eigene Projekt geflossen und diese Abhängigkeiten sind aus mannigfaltigen Gründen dem Zugriff des Entwicklers entzogen.
Wenn es eine beliebte Sammlung von Bibliotheken für Java Entwickler gibt, dann ist dies wohl Apache Commons. Für jede Art von Problem eines Java Entwickler gibt es dort eine Methode, die eine einfache Lösung verspricht.
Das automatisierte Erstellen von Software hat eine lange Tradition. GNU Make erblickte 1976 das Licht der Welt, Apache Ant im Jahr 2000, Apache Maven 2002 und Gradle 2007. Dies sind nur die bekanntesten Tools zur Build Automatisierung, viele weitere sind bis heute entstanden und es werden wohl noch einige erfunden werden. Alle diese Tools haben ihre Vorzüge und Nachteile und je nach Projekt und Technologie bietet sich eine Tool besonders an. Häufig kommt ein Entwicklungsteam mit den Maven Standard Plugins aus. Hin und wieder gibt es aber den Moment, wo ein zusätzliches Plugin wünschenswert wäre.
Mit Spring Boot können eigene REST Services schnell erstellt werden. Die dabei notwendige Validierung der Parameter ist mit dem Bean Validation Framework (JSR 380) auch in Windeseile hinzugefügt. Manchmal ist es aber notwendig verschiedene Parameter gegeneinander zu prüfen, dann reichen die Standardwerkzeuge nicht mehr aus und eigene Validatoren müssen erstellt werden. Anhand eines kleines Beispiel zeigt dieser Beitrag, wie einfach das geht.
Das Zitat „Die Unit Tests schreibe ich immer zum Schluss“ hat vermutlich schon jeder Entwickler von einem Kollegen hören müssen. Üblicherweise, wenn man bei einem schwerwiegenden Problem während der Implementierung helfen möchte. Ein kurzer Blick auf die Testergebnisse hilft dann enorm. Häufig zeigen die fehlgeschlagenen Unit Test direkt auf das Problem. Fehlen die Unit Tests, dann müssen sich die Entwickler solange durch GIT Historie und Debugger quälen, bis der eingeschleppte Fehler gefunden ist.
Die Bibliothek Mockito ist in der Test-Driven Software Entwicklung kaum noch wegzudenken. Die Möglichkeit komplexe Interaktionen mit APIs durch Mocks simulieren zu lassen, vereinfacht und beschleunigt die Implementierung eigener Anwendungen. Leider gibt es aber immer wieder kleine Stolperfallen in der Verwendung dieses ansonsten hervorragenden Framework.
Hin und wieder geben aktuelle Diskussionen den Anstoß über gerne und häufig verwendete Begriffe einmal etwas genauer nachzudenken. Im diesem Fall über die Technischen Schulden. Was ist damit gemeint und wie ist mit ihnen umzugehen?
Menschen machen Fehler und Software Entwickler benehmen sich in dieser Hinsicht auch sehr menschlich. Um die Zahl der Fehler in den Programmen zu reduzieren wurden daher schon früh verschiedene Vermeidungsstrategien entwickelt. Dies bekanntesten Strategien sind Tests und die statische Code Analyse.
Die Hauptaufgabe der Tests ist die Prüfung der korrekten Arbeitsweise der Software. Dafür wird das tatsächliche Verhalten mit dem erwünschten Verhalten verglichen. Die statische Code Analyse verfolgt eine andere Zielsetzung. Hier wird der Quellcode nach fehlerhafter oder unvorteilhafter Verwendung diverser Sprach-Konstrukte durchsucht. Bekannte Tools zur statische Code Analyse sind Checkstyle, PMD und SonarLint. In diesem Beitrag geht es um das Tool Error Prone aus dem Hause Google.