„Alte“ Software zu bearbeiten ist für viele Entwickler kein Vergnügen. Der Grund hierfür ist schnell gefunden: Je länger eine Applikation im Einsatz ist, desto mehr Personen haben bereits ihren programmiertechnischen Fingerabdruck hinterlassen. Oft wurden unterschiedliche Konzepte und Methodiken eingeführt, Libraries und Frameworks ausprobiert und so bildet sich langsam aber sicher ein bunter Zoo an Strukturen und Schnittstellen. Dabei gibt es Hilfsmittel und Strategien, um sich das Leben leichter zu machen und die Applikation auch längerfristig wartbar und erweiterbar zu halten.

Für die Wahl der richtigen Strategie zur Arbeit mit bestehender Software ist es wichtig, sich einen Überblick zu schaffen. Dazu gehört sowohl den bestehenden Code unter die Lupe zu nehmen als auch die zukünftigen Anforderungen zu kennen. Hilfreich ist an dieser Stelle, wenn man Zugriff auf die Entwickler der Applikation hat, denn sie kennen die dunklen Ecken im Quellcode. Die Analyse des bestehenden Quellcodes kann man sich am besten wie das Kartographieren einer unbekannten Landschaft vorstellen. Hier ist das Wissen über die Gefahrenstellen besonders wertvoll, da sich hier meist das größte Risiko für ein Scheitern des Gesamtprojekts verbirgt. Eine solche Projektübersicht sollte die wichtigsten logischen und fachlichen Einheiten der Applikation beinhalten sowie eine Kategorisierung in Impact und Komplexität. Daraus entsteht ein klares Bild über die Cheap Wins und die größten Baustellen. Zusammen mit den Produktverantwortlichen, in der agilen Entwicklung werden diese als Product-Owner (PO) bezeichnet, wird im Anschluss an die initiale Version weiter an der Projektübersicht gearbeitet. Das Wissen der POs über die Kunden und ihre Anforderungen hilft, die Projektübersicht weiter zu priorisieren. Die Priorisierung gibt bei der anschließenden Arbeit an der Applikation die Reihenfolge vor, in der an bestimmten Teilen der Applikation gearbeitet wird. Der Trick bei der Priorisierung ist, dass nicht zwischen wichtig und unwichtig unterschieden wird, da ansonsten alle Features wichtig sind und keines unwichtig, sondern die Features in eine klare Reihenfolge gebracht werden. Zu diesem Zweck müssen sich die POs mit den Entwicklern an einen Tisch setzen, um auch die technischen Abhängigkeiten abzubilden. Ein noch so wichtiges Feature kann nicht ohne eine solide technische Basis bestehen und die schönste Architektur hilft nichts, wenn die Applikation ihren Zweck nicht erfüllen kann.

Die Anforderung an die Modernisierung einer Applikation ist stets: Die Applikation soll nach erfolgter Modernisierung funktionieren wie zuvor und noch dieses und jenes Zusatzfeature aufweisen. Im Idealfall sind die Features in der Projektübersicht so detailliert beschrieben, dass ein Testplan daraus abgeleitet werden kann. Das Testing der Features sollte möglichst automatisiert werden, um Zeit und Ressourcen zu sparen. Diese Feature-Tests werden nach der Modernisierung nicht gelöscht, sondern begleiten die Applikation in ihrem weiteren Lebenszyklus und dienen der zukünftigen Absicherung der Features.

Mit einer Modernisierung lassen sich technologische Fehlentscheidung von unpassenden Strukturen und Architekturen bis hin zu den verwendeten Frameworks korrigieren. Die Auswahl der Werkzeuge hängt stark von der Aufgabenstellung ab. Gerade im Bereich der Webfrontends ist die Auswahl riesig und sehr dynamisch. Auch die Erfahrung im Team kann ausschlaggebend für die Technologieauswahl sein. Die meisten aktuellen Frameworks und Bibliotheken unterstützen eine komponentenorientierte Architektur, die generell hilfreich bei der Modernisierung bestehender Software ist, da diese dann komponentenweise modernisiert werden kann, beziehungsweise ein bestehendes Feature in eine neue Komponente ausgelagert werden kann. So ergibt sich auch der grundsätzliche Aufbau der Applikation. Als zentrale Plattform für die Verteilung von Javascript-Bibliotheken hat sich NPM durchgesetzt. Neben der reinen Verteilung von Paketen stellt NPM auch statistische Informationen über Pakete zur Verfügung, die bei der Auswahl einer Bibliothek in Betracht gezogen werden können. So erlaubt die Anzahl der wöchentlichen Downloads zum Beispiel einen groben Rückschluss auf die Popularität einer Lösung. Je höher diese Metrik ist, desto besser eignet sich die Software für den Einsatz in einer Applikation.

Gerade bei Frameworks, die einen großen Einfluss auf die Struktur der Applikation haben wie etwa Angular, React oder Vue, ist auch der Releasezyklus beziehungsweise die Updatepolitik wichtig. Im Fall von Angular erscheinen zweimal jährlich Major Releases. Das Framework folgt den Regeln des Semantic Versionings, nach denen es bei Major Releases zu Breaking-Changes kommen kann. Der Vorteil eines solchen getakteten Releasezyklusses ist, dass derartige Aktualisierungen gut planbar sind. Alle großen Frameworks kennzeichnen auch Funktionalitäten, die in kommenden Releases wegfallen werden, sodass entsprechend darauf reagiert werden kann.

Bei der Modernisierung gibt es generell die Auswahl zwischen einem kompletten Rewrite der Applikation und dem etwas weniger radikalen schrittweisen Refactoring. Bei einem Rewrite startet die Entwicklung der Applikation auf der grünen Wiese, der bestehende Quellcode wird komplett verworfen. Diese Art der Modernisierung lässt viele Freiheiten bei technischen Entscheidungen. Allerdings ist das Risiko des Scheiterns des Projekts deutlich höher. Bei einem Rewrite wird die neue Version der Applikation zu einem definierten Zeitpunkt livegeschaltet und die alte Version wird abgeschaltet. Spätestens dann müssen die Daten der bestehenden Applikation in die neue Applikation überführt werden. Die bessere Lösung für die Modernisierung einer Applikation liegt in einem schrittweisen Refactoring. In diesem Fall wird die neue technische Basis einer Applikation parallel zur bestehenden Applikation hochgezogen und die Features Schritt für Schritt in die neue Applikation migriert. Sobald ein Feature in der neuen Applikation umgesetzt ist, wird es in der bestehenden Applikation abgeschaltet. Sind alle Features migriert, kann die alte Applikation abgeschaltet werden und die neue Applikation übernimmt die alleinige Kontrolle. Beim Refactoring kann entweder die neue oder die alte Applikation den Kern der Applikation während der Transition bilden. Es wird in jedem Fall eine Brücke zwischen beiden Applikationen benötigt, die die Einbindung der Features übernimmt und Anfragen zwischen beiden Versionen der Applikation vornimmt.

Rewrites und Refactorings haben in der Regel ein definiertes Ende. Beim Refactoring endet der Prozess mit einem Big-Bang-Release. Das Refactoring ist zu Ende, sobald das alte System abgeschaltet ist. Damit ist die Modernisierung der Applikation jedoch bei weitem nicht beendet. Hören die Bemühungen an dieser Stelle auf, endet die Applikation früher oder später wieder an dem Punkt, wo eine Modernisierung erforderlich wird. Eine bessere Strategie an dieser Stelle ist eine kontinuierliche Modernisierung. In diesem Fall findet die Weiterentwicklung der Applikation sowie die Integration neuer Features wie gewohnt statt. Jedoch wird eine bestimmte Menge an Ressourcen darauf verwendet, den Quellcode der Applikation zu modernisieren. Außerdem sollte die Pfadfinderregel: „Hinterlasse jedes Stück Software ein bisschen besser als du es vorgefunden hast“ angewendet werden ;-)