Technische Schulden – Tilgen, Tilgen, Tilgen

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?

Bug Pattern in Eigenbau

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.

Fehler entfernen mit Error Prone

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.

@Deprecated Deadlock

Beim Aktualisieren von Bibliotheken finden sich immer wieder Methoden, die nicht mehr zeitgemäß sind. Denn häufig ermöglichen neuere Ansätze kompakteren, einfacheren oder eleganteren Code. Um den Nutzern der Bibliothek das Leben nicht zu erschweren, werden solche Methoden als veraltet (@Deprecated) markiert. Damit beginnt eine Gnadenfrist, in der die Nutzer ihren eigenen Code auf die neuen Alternativen umbauen müssen. Diese Frist endet, wenn die Entwickler der Bibliothek die veralteten Methoden löscht.

Der Rete Algorithmus (3)

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.

Implementierungen inkrementell verändern mit dem Branch By Abstraction Pattern

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.

Unterschiede finden mit dem Java Annotation Processor (Teil 2)

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.

Ab die Post (Teil 2)

Im vorherigen Beitrag zu JavaMail API wurde die Bibliothek GreenMail vorgestellt. Mit dieser Bibliothek ist es möglich, verschiedene E-Mail Server zu simulieren. Da keine überzeugende JUnit 5 Unterstützung existiert, lag die Idee nahe, eine eigene JUnit Extension zu schreiben. Während der Implementierung zeigten sich erste Ideen als unnütz, das Verständnis der GreenMail API verbesserte sich und die eigene Art zu Testen wirkte sich natürlich auf die Gestaltung der Erweiterung aus.

Fun with Refactoring

Leider verhält es sich mit TODOs wie mit den Flaggen an Nord- und Südpol. Sie überdauern die Jahre und sehen hin und wieder enttäuschte Gesichter von Abenteurern, die zu spät gekommen sind.

Kalenderspielereien mit Java – I18N

Die ersten drei Beiträge dieser Reihe handelten von einer Java API zur Feiertagsberechnung. In diesem Beitrag geht es um eine nachtragliche Verbesserung der Internationalisierung (I18N) und der minimalinvasiven Implementierung mit Hilfe des Decorator Design-Pattern.