Gedanken zur agilen Softwareentwicklung
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.
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.
Bei der Betrachtung einer Technologie keimt in einem Entwickler immer wieder eine Frage auf. Wieviel Aufwand muss investiert werden um eine eigene einfache Implementierung zu erstellen? Hinter dieser Frage steht dabei nicht unbedingt das leidige Anti-Pattern Reinventing the Square Wheel, sondern die konkrete Frage nach den Fähigkeiten des eigenen Teams.
Die Holidays Bibliothek aus dem Beitrag Kalenderspielereien mit Java hat schon seit geraumer Zeit keine Aktualisierung erfahren. Daher sollen einige Methoden hinzuzugefügt werden um den Umgang mit Werktagen zu vereinfachen.
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.
Im zweiten Beitrag zum Rete Algorithmus wurde eine erste einfache Implementierung vorgestellt. Schon bei der Umsetzung zeigte sich jedoch, dass diverse Details anders gelöst werden sollten. Es passiert recht häufig, dass sich eine zu enge Anlehnung an eine Beschreibung eines Algorithmus den Weg zu einer guten Lösung erschwert oder sogar verbaut. Aus ähnlichen Gründen blieb mir viele Jahre der Zugang zu einer korrekten Double-Array-Trie Implementierung versperrt. Auch dort bedurfte es erst einen neuen Zugang zum Thema um die Blockade zu beenden.
Nachdem im ersten Beitrag zum Rete Algorithmus die grundlegende Arbeitsweise beleuchtet wurde, geht es in diesem Beitrag um die Implementierung. Nicht um einen vollständigen OPS 5 Interpreter, sondern um die Bausteine, aus denen ein funktionsfähiges Rete Netz erstellt werden kann.
Der Rete Algorithmus wurde 1979 von Charles Forgy entwickelt und dient zur Auswertung von Regelbedingungen. Mit ihm ist es möglich die Vorbedingungen große Regelmengen effizient zu berechnen. Verwendet wurde der Rete Algorithmus in der regelbasierten Programmiersprache OPS 5. Aber auch heute arbeiten viele regelbasierte Systeme mit dem Rete Algorithmus oder einen seinen vielen Derivaten.
Hin und wieder sucht der Entwickler eine Möglichkeit alle Kombinationen einiger Werte zu generieren. Ein einfache und elegante Methode kann mit Streams und BitSets implementiert werden.
Als Software Entwickler lernt man immer wieder neue Varianten eindeutiger Kennzeichner kennen. Da gibt es die bekannten Kennzeichner wie die Telefonnummern, Kreditkartennummern, PLZ, ISBN, EAN-13, IATA, IBAN, BIC, die veraltete BLZ und nicht so bekannte wie die internationalen Patentnummern, Kreisgemeindeschlüssel und die Leitweg ID. Alle diese Kennzeichner müssen erkannt, geprüft, interpretiert und geschrieben werden können.