Michael C. Feathers beschreibt in seinem Buch Effektives Arbeiten mit Legacy Code aus dem Jahr 2004 insgesamt 24 Techniken, um Dependencies aufzuheben, Code testbar zu machen und das Design schrittweise zu verbessern. Die Techniken sind im Buch alphabetisch sortiert und wirken auf den ersten Blick oft sehr ähnlich. Dadurch ist es nicht immer leicht zu erkennen, welche Vorgehensweisen verwandt sind, welche Kernideen dahinterstehen und wann sie tatsächlich sinnvoll eingesetzt werden können.

In der Mode kommt alles wieder, sagt man. Vielleicht liegt es daran, dass sich für bestimmte kreative Aufgaben eben doch nur eine begrenzte Anzahl unterschiedlicher Lösungen finden lässt. Eine Hose ist halt entweder eng geschnitten oder weit – oder irgendetwas dazwischen. Was hat das mit Schnittstellen zu tun? Eine ganze Menge. Auch in der Softwareentwicklung begegnen uns ständig vermeintlich neue Trends: CORBA, SOAP, REST, APIs. Wer schon etwas länger dabei ist, merkt schnell, dass sich diese Ansätze oft weniger fundamental unterscheiden, als es die jeweiligen Schlagworte vermuten lassen.

Update 26.03.: Das Repo und die Slides sind hier Für den langfristigen Erfolg einer Anwendung ist unter anderem entscheidend, ob eine klare Architektur eingehalten wird. Damit wird sichergestellt, dass unser Code jederzeit wartbar bleibt und wir so zügig neue Features entwickeln können, ohne dabei Abstriche an der Qualität machen zu müssen. Um dieses Ziel zu erreichen, werden Anwendung oft in fachlich getrennte Module zerlegt, die möglichst stark entkoppelt sind. Dabei kann uns das Project Spring Modulith unterstützen.

Modularisierung und Modernisierung von Legacy-Software Wie man ein neues Projekt auf der grünen Wiese beginnt und dabei eine saubere Architektur baut, das wissen wir heute ganz gut. Aber die meisten von uns arbeiten ja in Projekten, die schon lange da sind und deren Architektur (vorsichtig gesagt) nicht mehr ganz so schön ist. »Monolith« und »Big Ball of Mud« sind die wenig schmeichelhaften Titel, die solchen Systemen verpasst werden. Die Teilnehmer lernen, wie sie ihre aktuellen Systeme bewerten und Schritte zur Einführung – oder Wiederherstellung – von Strukturen identifizieren können.

Zwischen JDK 8 und späteren Java-Versionen wurden zahlreiche Änderungen eingeführt. Jede Java-SE-Version kann kleinere Binär-, Source- oder Verhaltensinkompatibilitäten mit sich bringen. Mit der Modularisierung der Java-SE-Plattform ab JDK 9 kamen zusätzliche Herausforderungen hinzu, insbesondere beim Umgang mit internen APIs. Code, der ausschließlich offizielle Java-SE-APIs nutzt, sollte in der Regel weiterhin funktionieren. Anwendungen, die auf JDK-interne APIs zugreifen, können jedoch beim Kompilieren oder zur Laufzeit Probleme verursachen und sollten auf unterstützte APIs migriert werden.