Gedanken zur agilen Softwareentwicklung
Jens 
In den ersten und zweiten Beitrag dieser Reihe wurde ein Annotation Processor implementiert, der bei der Feststellung von Unterschieden zwischen zwei Java Beans unterstützt. In diesem Beitrag soll die Implementierung für Collection Klassen und Bean Strukturen erweitert werden.
Wer technische Dokumentationen erstellen muss, hat mit Asciidoctor eine einfache aber leistungsfähige Lösung zur Hand. Asciidoctor ist ein Textprozessor, der Vorlagen aus einfachen Textdateien in HTML, PDF, EPUB3 oder Docbook Format umwandelt. Durch die Asciidoctor API können dazu noch eigene Erweiterungen integriert werden.
Um eine bestehende Software Komponente umzubauen erstellt der Software Entwickler in der Regel einen Feature-Branch. In diesem Feature-Branch werden alle notwendigen Änderungen vorgenommen und das Ergebnis zurück in den Haupt-Branch gemerged. Unangenehm wird dieses Vorgehen, wenn die Änderungen aufwendig und langwierig sind. Denn je länger die Änderungen dauern, desto schwieriger wird es, die Änderungen in den Haupt-Branch zu integrieren. Dies liegt weniger an den Änderungen im Feature-Branch, sondern an den zwischenzeitlichen Änderungen am Haupt-Branch, der durch andere Feature-Branches unaufhörlich verändert wird. Eine Möglichkeit der Merge-Hölle von langlebigen Branches zu entgehen ist das Branch By Abstraction Pattern.
Im ersten Beitrag wurde die Implementierung eines AnnotationProcessor vorgestellt, der Vergleichsklassen erzeugte. Um zwei Instanzen einer Klasse ExampleBean zu vergleichen, muss nur ein spezielles Interface definiert werden, um automatisch eine passende Implementierung zu erhalten.
Ein traditionelles Problem in der Software Entwicklung ist die Bestimmung von Unterschieden zwischen zwei Instanzen einer Klasse. Um das Problem zu lösen gibt es eine ganze Reihe von Möglichkeiten.
In diesem Beitrag wird der Ansatz, eigenen Vergleichscode zu schreiben, mit der Verwendung einer AnnotationProcessor Implementierung verbunden, um den Vergleichs-Code automatisch erstellen zu lassen.
REST Services können nur eine gewisse Anzahl von Anfragen innerhalb eines Zeit Fensters verarbeiten. Werden zu viele Anfragen gestellt, dann gerät der Service unter Last und reagiert sehr langsam oder gar nicht mehr. Zusätzliche Anfragen, die ein vorgegebenes Limit übersteigen, sollten daher vom Service abgelehnt werden.
JUnit 5 bietet mit seiner Extension Model einen leichtgewichtigen Ansatz um Testdaten direkt in die jeweilige Testmethode zu injizieren. Im Beitrag Personas für Unit Tests wurde gezeigt, wie mit dem ParameterResolver und dem InvocationInterceptor Testdaten vor der Testausführung generiert und manipuliert werden können. Ausgeblendet wurde dabei die Zuweisung der Persona Eigenschaften auf die Testobjekte im FakePersonaBuilder.
Kostspielige Initialisierungen von lokalen Variablen müssen verzögert vorgenommen werden . Dabei werden häufig If-Konstrukte verwenden, die der Lesbarkeit des bestehenden Codes schaden.
Mit dem Extension Model von JUnit 5 gibt es Vielzahl neuer Möglichkeiten, das Schreiben von Unit Tests zu vereinfachen. In den Beiträgen Dependency Injection mit ParameterResolver in JUnit 5 und Zufallswerte in JUnit 5 wurde der JUnit 5 ParameterResolver behandelt. Dieser Beitrag stellt den InvocationInterceptor vor.
Bei der Verwendung von REST Schnittstellen beginnt die Evolution eigener APIs mit der Erstellung einiger HTTP Endpunkte die Informationen im JSON Format austauschen. Die nächste Stufe ist die Abkehr von der Denkweise in Aktionen hin zum Verständnis, dass über REST Resourcen addressiert und manipuliert werden.