Der lise Blog:
Einsichten, Ansichten, Aussichten

Das kleine ABC der Legacy-Software

In der Web-Technologie jagt ein neues Buzzword das Nächste. Um einen Kollegen zu zitieren: „Jeden Tag entsteht irgendein neues Hipster-JavaScript-Framework“. Im Bereich von Legacy-Software sieht es etwas besser aus, da nicht jeden Tag neue Trends entstehen.

Dennoch gibt es eine Fülle von Begriffen, die für Außenstehende verwirrend sind, da sich komplexe Zusammenhänge dahinter verbergen. Auch gibt es keinen Kanon, was die Bedeutung angeht. Ich möchte hier die wichtigsten Begriffe erläutern:
 

Legacy-Software

Der Begriff Legacy-Software oder Legacy-Code ist der zentrale Begriff und nirgends exakt definiert. Die verbreitetste Definition stammt von Michael Feathers:

  •  „Code ohne automatische Tests“

Ich finde, es genügt umgangssprachlich unter „Legacy-Software“ veraltete Software zu verstehen, also Software die ein paar Jahre alt ist. Das trifft sicherlich nicht immer zu und würdigt nicht die Bemühungen der Clean Code-Bewegung, aber es reicht zum groben Verständnis.
 

Refactoring

Mit Refactoring ist das Verändern von Quellcode gemeint, ohne das äußere Verhalten zu ändern. Ein Stakeholder/Anwender hat insofern keinen direkten Nutzen von Refactoring, da keine Verhaltensänderung beabsichtigt ist. Umgekehrt ist das Ausbleiben von Refactoring für den Stakeholder/Anwender spürbar: Features brauchen länger, um entwickelt zu werden oder die Software wird fehleranfälliger.
 

Software-Sanierung, Software-Reparatur, Software-Modernisierung und Software-Evolution

Die vier Begriffe Software-Sanierung, Software-Reparatur, Software-Modernisierung und Software-Evolution haben keine einschlägig bekannte Definition. Sie werden eher herangezogen, um die Thematik im Vergleich zum Hausbau zu verdeutlichen.
 

Software-Sanierung

Ist die Software nicht mehr benutzbar, so muss sie saniert werden. Dies kann zum Beispiel eintreten, wenn Software lange nicht genutzt wurde und auf aktuellen Systemen nicht läuft. Sie muss dann Stück für Stück an die neuen technischen Anforderungen angepasst werden. Es bietet sich an, die Anforderungen durch Reverse-Engineering zu erarbeiten und Alternativen zur Legacy-Software abzuwägen.
 

Software-Reparatur

Software-Reparatur ist nötig, wenn einzelne Bestandteile der Software nicht mehr funktionieren, die Software aber grundsätzlich lauffähig ist. Das Entfernen von Fehlern und das Beschleunigen der Software sind übliche Aufgaben. Meist geschieht dies im Rahmen eines Wartungsvertrags, sodass zusammen mit der Reparatur oft auch neue oder geänderte Anforderungen umgesetzt werden. Ähnlich, wie bei der Reparatur eines Autos oder eines Gebäudes lohnt sich die Reparatur, wenn die Software grundsätzlich den Anforderungen (technisch und fachlich) entspricht.
 

Software-Modernisierung/-Evolution

Falls die Software dem technischen Umfeld nicht mehr genügt, kann eine Modernisierung sinnvoll sein. Dies ist der Fall, wenn die Legacy-Software nicht genügend mit den gewachsenen Datenmengen skaliert, sich die Infrastruktur ändert (zentralisierte Server) oder der Lebenszyklus von Dritt-Software (Betriebssysteme, Datenbanksysteme) endet. Bei der Software-Modernisierung werden die

  • einzelnen fachlichen und technischen Komponenten der Software (zum Beispiel Frontend/Backend),
  • Dritt-Software (Betriebssysteme, Datenbanken, Server- und Laufzeitumgebungen) und
  • eingesetzte Sprachen und Frameworks

unter die Lupe genommen und bewertet. Mit dem zugrundeliegenden Wissen kann ein Modernisierungsplan erstellt werden, um einzelne Komponenten zu modernisieren oder abzulösen. Die Modernisierung ist ein iterativer Prozess und kann so weit gehen, dass am Ende die Software komplett ausgetauscht ist.
 

Software-Archäologie

Ist bei einem Legacy-System die SOLL-Architektur nicht bekannt, muss sie erarbeitet werden. Da sich das Bestimmen des IST-Zustandes der Architektur wie eine Ausgrabung anfühlt, wird dies als Software-Archäologie bezeichnet.
 

Technische Schulden

Die interne Qualität einer Software kann von Anwendern/Außenstehenden fast nicht beurteilt werden. Fehlende interne Qualität äußert sich nur indirekt in Form von Fehlern und langen Entwicklungszeiten.

Beispiele für technische Schulden sind:

  • fehlende automatische Tests
  • fehlerhafte/fehlende Dokumentation
  • Verletzung von Programmierparadigmen (CleanCode)
  • unbenutzter Alt-Code
  • „Gewachsene Struktur“ (SOLL-Architektur weicht stark von IST-Architektur ab)
  • veraltete Drittsysteme (Frameworks, Bibliotheken)

Der Begriff „technische Schulden“ etablierte sich dadurch, dass er die Kostenzunahme verdeutlicht. Technische Schulden können entweder bewusst oder unbewusst aufgenommen werden (in dem zum Beispiel auf eine Dokumentation oder Tests verzichtet wird). Gemeinsam haben sie aber immer, dass ein nachträgliches Beseitigen der Qualitätsmängel mit deutlich höheren Kosten verbunden ist.
 

Grüne Wiese

„Grüne Wiese“-Projekte sind Projekte, bei denen nicht auf bestehender Software aufgebaut wird. Die Grüne Wiese ist somit das Gegenstück zu Legacy-Software.
 

Testharnisch

Mit einem Testharnisch bezeichnet man eine große Anzahl automatischer Tests für eine Software. Die automatischen Tests stellen sicher, dass sich die Funktionalität einer Software bei Änderung nicht unerwartet verändert.

Ich persönlich glaube, dass der Begriff Testharnisch aus dem Englischen falsch übersetzt wurde. Die engl. Bezeichnung „test-harness“ lässt sich auch mit dem Geschirr übersetzen, welches aus Gurten besteht und zum Beispiel beim Klettern oder bei Tieren (Pferde/Hunde) eingesetzt wird. Meines Erachtens wäre Testgeschirr eine deutlich treffendere Übersetzung.
 

Seam (Säume)

Mit Säumen werden in Legacy-Software Stellen im Quellcode bezeichnet, bei denen man die interne Funktionalität einer bestehenden Software beobachten, testen oder überwachen kann, ohne dass die eigentlichen Quelltexte verändert werden müssen. Ähnlich wie bei einem Saum kann man in das bestehende System etwas „einnähen“.

Säume eignen sich daher hervorragend, um die bestehende Software durch Tests abzusichern.
 

Common-Law-Feature

Unter einem Common-Law-Feature versteht man ein Verhalten oder eine Funktionalität von Software, welche in der Form entweder nicht gewünscht war oder sinnvoll ist. Wenn genügend Zeit verstreicht, wird das ungewollte Verhalten nicht nur akzeptiert, es wird sogar erwartet! Ab dann ist es ein Common-Law-Feature.

Ein bekanntes Common-Law-Feature ist der „Speichern“-Knopf in Computerprogrammen. Aufgrund der extrem gestiegenen Geschwindigkeit von Hardware ist es eigentlich nicht nötig, dass manuell gespeichert werden muss. Die Software könnte dafür sorgen, dass Änderungen immer sofort persistiert werden. Schreibt man einen Text auf Papier, muss man den auch nicht speichern, damit der Text draufbleibt. Dennoch fühlt es sich komisch an, wenn der Speichern-Knopf fehlt, oder?

Wer noch mehr über die neusten Softwaretechnologien- und Trends erfahren möche, dem lege ich die lise Academy ans Herzen. Dort bieten wir Tranings und Workshops an, die von Entwickler für Entwickler sind - alles auf Augenhöhe.

Zur lise Academy 

 

 

Foto: ninocare, pixabay

Diesen Artikel weiterempfehlen

 Teilen  Teilen  Teilen  Teilen