Softwaresanierung

Softwaresanierung ist eine Alternative zur Neuentwicklung von Altsystemen. Das zentrale Anliegen einer Sanierung ist es, eine in die Jahre gekommene Software wieder fit für die Zukunft zu machen. Anders, als bei der Softwarewartung, geht es bei der Sanierung nicht nur darum, die Software irgendwie am Leben zu halten, sondern es geht um die Änder- und Erweiterbarkeit einer existierenden Altsoftware. Diese beiden Eigenschaften fassen wir unter dem Begriff Feature-Fähigkeit zusammen.

Feature-Fähigkeit

Feature-Fähigkeit beschreibt die Eigenschaft eines Softwaresystems auf neue oder geänderte Anforderungen angemessen reagieren zu können. Angemessen bedeutet in diesem Zusammenhang, dass die Änderung bzw. Erweiterung in akzeptabler Zeit sowie regressionsfrei durchgeführt werden kann.

Altsysteme sind i.d.R. nicht Feature-Fähigkeit. Zum einem weist der Quellcode oftmals eine so hohe Technische Schuld auf, dass Entwickler keine Ansatzpunkte für sichere Anpassungen finden, ohne den Code vorher grundlegend aufzuräumen. Zum anderen führt jede Änderung zu unvorhersehbaren Regressionen, die aufgrund nicht vorhandenere Tests erst vom Kunden gefunden werden. Folglich ist das Altsystem nicht mehr erweiterbar.

Feature-Fähigkeit beinhaltet zwei zwingende Voraussetzungen: Automatisiertes Deployment und Automatisierte Tests.

Automatisiertes Deployment

Automatisiertes Deployment bezeichnet das automatische Bauen, Packen und Ausliefern sämtlicher Software-Artefakte der Altsoftware, basierend auf einem bestimmten Versionsstand. Die Bezugnahme auf eine Softwareversion setzt das Vorhandensein eines Version Control Systems (VCS) voraus. Dieses ermöglicht das gezielte Deployment eines bestimmten Versionsstands der Software, sowie ein sicheres Zurückrollen auf einen Vorgängerstand im Fall eines fehlerhaften Deployments.

Automatisierte Tests

Automatisierte Software-Tests überprüfen die Funktionsfähigkeit der Software auf Knopfdruck. Tests werden idealerweise nach jeder Änderung ausgeführt und stellen sicher, dass die Änderungen keine Regression bewirkt. Eine gute Testabdeckung entsteht, wenn jede Änderung und Erweiterung durch automatisierte Tests abgesichert wird. Dies ist in Altsystemen fast immer vernachlässigt worden. Die einziger Chance ist das Herstellen nachträglicher Testbarkeit.

Altsysteme lassen sich so gut wie nie von innen heraus testen. Erstens gibt der vorhandene Sourcecode dies nicht her und zweites gewinnt man wenig mit dem Testen einzelner Klassen oder Funktionen. Stattdessen gilt es, Tests so weit außen wie möglich zu schreiben. Je nach Technologie gibt es dafür verschiedene Ansätze. In API-Projekten ist das einfach, da diese die sich mit Hilfe von Standard-HTTP-Clients skripten und automatisiert testen lassen. Auch für Web-Anwendungen gibt es inzwischen eine Vielzahl von Tools zur Testautomatisierung. Aber wie sieht es zum Beispiel mit alten Delphi-Anwendungen aus, deren einziger Zugang eine Windows-GUI ist? Bei dieser Art von Systemen kann Robotic Process Automation ein vielversprechender Ansatz sein.

Automatisiertes Deployment und Automatisierte Tests sind die Basis jeder Feature-Fähigkeit und gehören deshalb nach ganz oben ins Sanierungs-Backlog.

Software-Sanierung

Deploy- und Testbarkeit macht die Software änderbar und damit sanierbar. Sanierung findet immer vor dem Hintergrund eines konkreten Features statt. Entweder muß bestehende Funktionalität geändert, oder es muß ein komplett neues Feature entwickelt werden. Beide Varianten beinhalten zwei Phasen: Aufräumen und Entwicklung.

Die Aufräumphase schafft die Voraussetzung für die Entwicklung des Features. Ähnlich dem Refactoring geht es in dieser Phase darum, das Design des existierenden Systems besser zu machen und Ansatzpunkte für Erweiterungen zu schaffen. Während Refactoring aus kleinen, inkrementellen und überschaubaren Code-Anpassungen besteht, ist das Aufräumen einer Sanierung eher mit einem Bagger-Ansatz vergleichbar. Es werden richtige Baustellen aufgerissen, die darüber hinaus über längere Zeit bestehen.

Ein verbreiteter Sanierungsansatz ist das Aufsplitten von monolithischen Altanwendungen in Microservices. Statt Abriss und Microservice-basierter Neuentwicklung besteht ein möglicher Sanierungsansatz darin, einzelne Teile aus dem Monolithen herauszuschneiden und als dedizierte Services zu betreiben. Damit das möglich ist, muß der Monolith um Zugänge erweitert werden, die einem ausgelagerten Service Zugriff auf benötigte Daten gewähren. Je nach Architektur bieten sich verschiedene Ansätze: Datenbank, Events oder HTTP-APIs.

Der Aufräumphase schliesst sich die Entwicklungsphase der Sanierung an. Microservice-basierte Entwicklung ist einfach, da diese aus der Entwicklung eines kleinen, eigenständigen Systems besteht, das relativ wenig Berührungspunkte mit dem Altsystem hat.