© Excellent backgrounds/Shutterstock.com
Java Magazin
Legacy-Code refaktorisieren mit Spring, Aspekten und Annotationen

Keine Macht dem Boilerplate-Code

Der Umgang mit Legacy-Code ist ein ebenso leidiges wie spannendes Thema für Entwickler. Auf den folgenden Seiten beschäftigen wir uns mit einer in die Jahre gekommenen Anwendung, der ein technologisches Upgrade spendiert wurde. Mit Annotationen und Aspekten bewaffnet sagen wir dem Boilerplate-Code den Kampf an.

Johannes Dienst


So ziemlich jeder Entwickler wurde schon mit der Wartung älterer Applikationen betraut. Im besten Fall ist man selbst der Urheber, und der Code ist durch fehlende technologische Upgrades und natürlich mangelnde Zeit in die Jahre gekommen. Im schlimmsten Fall hat man es mit alten Anwendungen zu tun, an denen hier und da zusätzliche Features dazu geschustert wurden, während der zuständige Kollege schon längst das Unternehmen verlassen hat. Dann wühlt man sich durch verwirrende Funktionsaufrufe und scheut sich vor Veränderungen, da sie zu unvorhersehbaren Nebeneffekten führen können. Doch hin und wieder kann man die Gelegenheit beim Schopfe packen und alles ein bisschen „besser“ machen. Unter besser verstehe ich vor allem wartbarer und damit lesbarer.

Genau das wurde möglich bei meinem aktuellen Beispiel. Das lief noch unter Java 1.4 und einer der ersten Spring-Versionen (die mit nur einem JAR). Dieses wurde auf eine aktuelle Version von Java und Spring portiert. Neben Generics, die alleine für sich schon viele Unklarheiten und Unsauberkeiten beseitigten, führte Java ab Version 5 auch Annotationen ein. Damit war es endlich möglich, Konfiguration und Implementierung von Komponenten in einer Klasse unterzubringen. Das Ziel im vorliegenden Projekt war es, die Lesbarkeit und Wartbarkeit um ein Vielfaches zu erhöhen, sodass Änderungen wieder ein bisschen einfacher implementiert werden konnten. Zusammen mit Spring und der vorhandenen AspectJ-Integration, mit denen sich Aspekte fast ausschließlich über Annotationen definieren lassen, lässt sich hier Einiges erreichen.

Der Istzustand

In Listing 1 zeigt sich beispielhaft der Istzustand der Codebasis. Zuerst fällt die Klassenvariable logger auf, die wir in jeder Klasse mit dem jeweiligen Klassennamen als String initialisieren müssen. Weiter sticht vor allem das Logging im Debug-Modus bei Methodeneingang bzw. -ausgang unangenehm heraus. Dann wird der eigentliche funktionsträchtige Code zusätzlich in einen try/catch-Block gepackt, damit wir im Fehlerfall auch eine Logausgabe bekommen. Folgende vier Probleme fallen ins Auge:

Beim Erstellen einer neuen Klasse verletzt man unweigerlich das DRY-Prinzip [3], indem man die Initialisierung des Loggers, der Bequemlichkeit halber, aus einer anderen Klasse kopiert und anpasst. Durch Unachtsamkeit vergisst man schnell, den Klassennamen entsprechend anzupassen, und schon haben wir Logausgaben mit falscher Klassenauszeichnung, die Verwirrung stiften. Ähnliches gilt für die Variable me...

Java Magazin
Legacy-Code refaktorisieren mit Spring, Aspekten und Annotationen

Keine Macht dem Boilerplate-Code

Der Umgang mit Legacy-Code ist ein ebenso leidiges wie spannendes Thema für Entwickler. Auf den folgenden Seiten beschäftigen wir uns mit einer in die Jahre gekommenen Anwendung, der ein technologisches Upgrade spendiert wurde. Mit Annotationen und Aspekten bewaffnet sagen wir dem Boilerplate-Code den Kampf an.

Johannes Dienst


So ziemlich jeder Entwickler wurde schon mit der Wartung älterer Applikationen betraut. Im besten Fall ist man selbst der Urheber, und der Code ist durch fehlende technologische Upgrades und natürlich mangelnde Zeit in die Jahre gekommen. Im schlimmsten Fall hat man es mit alten Anwendungen zu tun, an denen hier und da zusätzliche Features dazu geschustert wurden, während der zuständige Kollege schon längst das Unternehmen verlassen hat. Dann wühlt man sich durch verwirrende Funktionsaufrufe und scheut sich vor Veränderungen, da sie zu unvorhersehbaren Nebeneffekten führen können. Doch hin und wieder kann man die Gelegenheit beim Schopfe packen und alles ein bisschen „besser“ machen. Unter besser verstehe ich vor allem wartbarer und damit lesbarer.

Genau das wurde möglich bei meinem aktuellen Beispiel. Das lief noch unter Java 1.4 und einer der ersten Spring-Versionen (die mit nur einem JAR). Dieses wurde auf eine aktuelle Version von Java und Spring portiert. Neben Generics, die alleine für sich schon viele Unklarheiten und Unsauberkeiten beseitigten, führte Java ab Version 5 auch Annotationen ein. Damit war es endlich möglich, Konfiguration und Implementierung von Komponenten in einer Klasse unterzubringen. Das Ziel im vorliegenden Projekt war es, die Lesbarkeit und Wartbarkeit um ein Vielfaches zu erhöhen, sodass Änderungen wieder ein bisschen einfacher implementiert werden konnten. Zusammen mit Spring und der vorhandenen AspectJ-Integration, mit denen sich Aspekte fast ausschließlich über Annotationen definieren lassen, lässt sich hier Einiges erreichen.

Der Istzustand

In Listing 1 zeigt sich beispielhaft der Istzustand der Codebasis. Zuerst fällt die Klassenvariable logger auf, die wir in jeder Klasse mit dem jeweiligen Klassennamen als String initialisieren müssen. Weiter sticht vor allem das Logging im Debug-Modus bei Methodeneingang bzw. -ausgang unangenehm heraus. Dann wird der eigentliche funktionsträchtige Code zusätzlich in einen try/catch-Block gepackt, damit wir im Fehlerfall auch eine Logausgabe bekommen. Folgende vier Probleme fallen ins Auge:

Beim Erstellen einer neuen Klasse verletzt man unweigerlich das DRY-Prinzip [3], indem man die Initialisierung des Loggers, der Bequemlichkeit halber, aus einer anderen Klasse kopiert und anpasst. Durch Unachtsamkeit vergisst man schnell, den Klassennamen entsprechend anzupassen, und schon haben wir Logausgaben mit falscher Klassenauszeichnung, die Verwirrung stiften. Ähnliches gilt für die Variable me...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang