Regelmäßige Refactorings sind wichtig, gerade bei gewachsenen Legacy-Systemen – das ist mittlerweile allen klar. Typischerweise werden einfache Refactorings bereits in der IDE angeboten. Diese lassen sich dann kontinuierlich im Entwickler-Alltag einsetzen, indem die Pfadfinderregel aus dem Clean Code Development einsetzt wird. Allerdings gibt es auch größere, strukturelle Refactorings, die in deutlich mehr manuellem Aufwand resultieren. Hier setzen Werkzeuge an, die es ermöglichen, kompliziertere Regeln auf die gesamte Codebasis anzuwenden. Dazu gehe ich in diesem Blog-Artikel auf OpenRewrite ein und zeige wie leistungsfähig es ist.
Wie funktioniert das?
OpenRewrite kann Quellcode einlesen und in ein eigenes Modell überführen. Der resultierende Syntaxbaum wird hier „Lossless Semantic Tree“ genannt. Lossless an der Stelle meint, dass auch Whitespaces und die Formatierung erhalten bleibt. Auf diesem Modell bzw. Syntaxbaum können beliebige Transformationen – genannt Recipes – ausgeführt werden. Aus diesem Modell wird anschließend wiederum Code erzeugt, den der Entwickler dann begutachten und übernehmen kann. Diese Recipes können entweder selbst entwickelt werden oder es kann aus mehr als 500 vorgefertigten Recipes gewählt werden. Um OpenRewrite laufen zu lassen, muss es per Maven oder Gradle in den eigenen Build integriert werden. Dafür gibt es entsprechende Plugins. Neben Java werden weitere Formate – wie YAML oder XML – unterstützt und lassen sich so automatisiert verändern.
Gibt es Alternativen?
Ja, die gibt es. Meine Kollegen hatten in der Vergangenheit Eclipse JDT benutzt. Auch damit lässt sich Quellcode parsen und verändern. Leider ist das zum großen Teil an die Eclipse IDE gebunden, so dass man typischerweise ein kleines Eclipse-Plugin bereitstellen muss, mit dem das programmierte Refactoring angestoßen werden kann. Hier lässt sich prinzipiell das gleiche Ergebnis erzielen, wenn man eigene Regeln programmieren will. Allerdings lässt sich das nicht einfach headless betreiben, so dass es bei sehr großen Projekten schwierig wird, die Regel auf die gesamte Codebasis anzuwenden. Eclipse büßt meiner Erfahrung nach bei hinreichend großen Projekten einiges an Performance ein. Bei OpenRewrite muss man dafür nicht alles in die IDE laden, sondern kann dies per Maven oder Gradle starten. Außerdem ist eine Beschränkung auf Eclipse problematisch, wenn wie bei uns auch andere IDEs wie Visual Studio Code oder IntelliJ verwendet werden.
Eine ganze Bibliothek
Ein weiterer Vorteil von OpenRewrite ist die Vielzahl von Standard-Refactorings. Zum einen gibt es hier vollständige Refactorings, die zum Beispiel typische Findings aus statischer Codeanalyse beseitigen, wie z.B. ungenutzte Variablen oder ungenutzte Methoden. Zum anderen gibt es Refactorings, die auf das Upgrade einer Library abzielen. So gibt es in OpenRewrite vorgefertige Refactorings, die beispielsweise die Umstellung von Spring Boot 1 auf Spring Boot 2 vornehmen. Darüber hinaus gibt es auch noch parametrisierbare Refactorings, die man sich dann wiederum wie in einem Baukastensystem zusammenstellen kann. Beispiele hierfür sind bekannte Refactorings aus der IDE-Welt, wie z.B. das Umbenennen eines Packages. So lassen sich ganze Sequenzen über das Buildsystem automatisieren und ausführen.
Lass der Fantasie freien Lauf
OpenRewrite ist ein sehr mächtiges Werkzeug. Letztlich lässt sich damit alles umsetzen, was sich regelbasiert ausdrücken lässt. Als ich mit meinen Kollegen über dieses Tool sprach, waren diese sofort begeistert: „Cool, was man damit so machen kann!“. Aber im ersten Moment war nicht sofort klar, wozu man das ganz konkret bei uns einsetzen kann. Aber in der weiteren Diskussion kamen dann nach und nach immer mehr Ideen. Beispielsweise war bislang die vollständige Umstellung auf JUnit5 in weiter Ferne. Mit OpenRewrite wird das Ziel greifbar, da ein Großteil der Arbeit automatisiert erfolgt. Ein anderes Beispiel ist die Einführung von Konventionen: Ein eigenes Recipe sorgt dafür, dass Klassen eines bestimmten Typs einem einheitlichen Namenspattern folgen. Das macht den Code übersichtlicher und besser verstehbar. Wenn man für solche Gelegenheit Augen und Ohren offen hält, werden damit Dinge möglich, die man aus Aufwandsgründen bislang gescheut hat.
Habt ihr bereits Erfahrungen mit solchen Tools gemacht? Lasst es mich gerne wissen auf LinkedIn.
