Gedanken zur agilen Softwareentwicklung
Schon im Beitrag Stammbaumprüfung mit BPMN wurde der Einsatz von BPMN Workflows in einer Workflow-Engine vorgestellt. Im damaligen Beitrag wurde die Workflow-Engine Flowable verwendet. In diesem Beitrag dreht es sich um die Workflow-Engine Camunda. Wer eine neuen Workflow erstellt hat, möchte diesen natürlich auch gerne im Vorfeld testen. Dafür stellt auch Camunda eine JUnit 5 Unterstützung bereit.
Für manche Kollegen ist das Textsatzsystem TeX mit seinem Aufsatz LaTeX ein Dinosaurier. Dieser Dino ist aber quicklebendig und bietet immer wieder preisgünstige Lösungen für unerwartete Anforderungen.
Im ersten Kafka Beitrag ging es um die generelle Arbeitsweise und Architektur des Systems. In diesem Beitrag um die Integration in eigene Spring Boot Anwendung. Dieser Beitrag wird recht kurz, weil die Integration tatsächlich sehr einfach ist.
Im ersten Teil dieses Beitrags wurde ein Ansatz zur Validierung von Datumsangaben vorgestellt, der auf der Angabe von expliziten Zeitfenstern beruht. Damit keine Angaben weit in der Zukunft getätigt werden können, wird der Zeitraum direkt in der Validierungs-Annotation beschränkt.
Die erste Implementierung hatte den Nachteil, dass sie nur für den Type LocalDate bereitstand. In diesem Beitrag wird beschrieben, welche Änderungen nötig sind um auch weitere Typen zu unterstützen. Zusätzlich werden auch Zeitfenster in die Vergangenheit implementiert.
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.
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.
Wer sich mit Micro Services und insbesondere mit dem Thema Event-Driven Microservice Architecture beschäftigt, wird um Apache Kafka nicht herumkommen. Bei Apache Kafka handelt es sich um ein überaus populäres Publish/Subscribe Messaging System, das bei vielen namhaften Firmen und Organisationen verwendet wird.
Der Spring Boot WebClient ist der reaktive, nicht blockierende Alternative zum RestTemplate. Obwohl der WebClient für die Anwendung in reaktiven Anwendungen entworfen wurde, kann er auch in klassischen Anwendungen das RestTemplate ersetzen. Insbesondere die moderne Implementierung und die Fluent API sind es, die den Software Entwickler die Entscheidung für den WebClient leicht machen. Obwohl die Fluent API des WebClient ein Segen für die Entwicklung ist, stellt sie einen Fluch für die Unit Tests da.
Im verherigen Beitrag zur statischen Code Analyse mit Error Prone wurde die Möglichkeit erwähnt, eigene Bug Pattern prüfen zu lassen. In diesem Beitrag wird nun ein BugChecker implementiert, der ein störendes Bug Pattern erkennt und patchen kann.
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.