Gedanken zur agilen Softwareentwicklung
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.
Im ersten Beitrag wurde aus der Vogelperspektive beschrieben, wie die FreshMarker Template-Engine zu bedienen ist. Ausgelassen wurde dabei, wie aus der Textdarstellung eines Templates eine Instanz der Klasse Template generiert wird. Um ein Template syntaktisch korrekt und sauber zu verarbeiten, bietet es sich an, einen passenden Parser zu verwenden. Mit dem Parser-Generator JavaCC 21 von Jonathan Revusky steht das passende Werkzeug zum Erzeugen eines eigenen Parsers zur Verfügung. JavaCC 21 liefert erfreulicherweise auch eine eigene FreeMarker Grammatik, mit der die eigene Entwicklung zügig beginnen kann.
In mancher Java Anwendung befinden sich Legacy Code Einschlüsse um JDBC Anfragen, die nicht mehr zeitgemäß erscheinen. Häufig wünscht sich der Entwickler, den recht plumpen Code durch eine elegante Stream Variante zu ersetzen. In dem Beitrag JPA Tabellen mit reservierten Nummernkreisen wurden IDs aus einer Tabelle ausgelesen, um den größten gefundenen Wert als Basis für zukünftige IDs zu nutzen. Der ursprüngliche Code arbeitet mit einer while-Schleife, die über ein ResultSet iteriert.
“Beziehungen bleiben bestehen aber Bedürfnisse ändern sich”. So oder so ähnlich heißt es in einer schlüpfrigen Fernsehwerbung zu später Stunde. Bei Microservices finden sich aber tatsächlich immer wieder Situationen, bei denen zwei Microservices besser harmonieren, wenn ein dritter involviert ist.
Wie auch der vorherigen Beitrag handelt dieser über Microservices als Architekturkonzept und die dort verwendeten Design Pattern. Bei dem Microservice Pattern Domain Events handelt es sich um die Nutzung von fachlichen Ereignisse aus dem Bereich Domain-Driven Design. Die Microservices kommunizieren also nicht nur über direkten Nachrichtenaustausch mit ihnen bekannten Services, sondern sie signalisieren auch Änderungen an entkoppelte, ihnen unbekannte Services.
Mikroservices stellen ein eigenes Architekturkonzept dar, mit denen Anwendungen dezentral und entkoppelt entwickelt und betrieben werden können. Eine große Anzahl von Design Pattern macht es den Entwicklern dabei einfach, gute Architekturen zu erstellen. Die Mikroservices Architektur wirkt sich jedoch nicht nur auf die Software aus, sondern bietet auch viel Potenzial um die Arbeit der Teams zu verbessern. Wie dies im speziellen aussehen kann soll an dem sehr grundlegenden Pattern Database Per Service dargestellt werden.
Ein großes Missverständnis bei der Verwendung von Microservices, ist die Annahme, es wären einfach nur sehr kleine Services. Diese Herangehensweise führt zwar schnell zu beträchtlichen Erfolgen, sie fördert aber mittel- und langfristig Fehler in ihrer Betrachtung, Verwendung und Entwicklung.
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.
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.
Bei jedem Beitrag zum Visitor Pattern habe ich die Vermutung, es wird wohl der letzte zum Thema sein. Aber nur knapp drei Monate nach “Kalenderspielereien mit Java – iCalendar” folgt schon ein neuer Beitrag zu diesem Design-Pattern.