Artikel versenden

Bauen wir Legacy Anwendungen?




 

// / /

In einer der letzten Ausgaben des Objektspektrums fand sich ein Erfahrungsbericht über ein erfolgreiches Refactoring einer Legacy-Anwendung. Die Altanwendung zeichnete sich dabei – wie üblich – durch fehlende Dokumentation und hohe Komplexität des Sourcecodes aus. Soweit ist das nichts Neues. Bemerkenswert fand ich aber, dass die beschriebene Legacy-Anwendung kein Cobol-Urgestein aus der Frühzeit der Informatik war, sondern eine erst sechs Jahre alte Java-Anwendung. Wie kann es sein, dass eine so junge Applikation als nicht mehr wartbar angesehen wird? Oder anders herum gefragt: Wie müssen wir in unseren Projekten vorgehen, um nicht jetzt die Legacy-Anwendungen von morgen zu schaffen?

Ein wichtiger Punkt dabei ist sicherlich, die Software zum Projektabschluss in einem ordentlichen Zustand in den Betrieb zu übergeben. Refactorings sollten während der gesamten Projektlaufzeit durchgeführt werden, so dass zum Projektende keine wesentlichen Architekturschulden mehr vorhanden sind. Auf den letzten Drücker unter hohem Zeitdruck noch eben schnell die letzten „nice to have“-Feature umzusetzen, ist hingegen eine ziemlich sichere Methode den Code noch gründlich in Unordnung zu bringen.

Doch ist ein aufgeräumter Code alleine hinreichend, um die Applikation langfristig lebensfähig zu halten? Was ist z.B. mit Anwendungen, die von externen Dienstleistern entwickelt und intern betrieben werden? Häufig wird eine solche Anwendung nicht sofort weiterentwickelt, sondern es werden erst einmal Änderungswünsche gesammelt. Womöglich soll dann nach einem halben Jahr ein Update von einem Team durchgeführt werden, das in keiner Weise mit der Realisierung der ersten Version befasst war. Die vorhandene Software muss dann erst einmal in ihrer Struktur und Funktionsweise verstanden werden.

Meiner Erfahrung nach ist gut strukturierter und kommentierter Code hierbei hilfreich und bei anschließendem Bohren in die Tiefe auch zwingend notwendig. Um sich aber einen Überblick über die Anwendung zu verschaffen und ihre Struktur zu verstehen, ist der Blick in den Sourcecode zu detailliert. Hierbei helfen Dokumentationen jeder Art, insbesondere Struktur- und Ablaufdiagramme wesentlich weiter. Diese wiederum sind natürlich nur dann wertvoll, wenn sie auch im Einklang mit dem tatsächlichen Stand der Anwendung sind.

Beim Start eines Projektes entwickelte Strukturdiagramme sind beim Abschluss sicherlich nicht mehr vollständig synchron mit der Applikation und helfen dementsprechend auch nicht beim Versuch, die Anwendung zu verstehen. Wir brauchen also Formen der Dokumentation, die einerseits helfen, die Struktur einer Anwendung zu verstehen und die andererseits während eines Projektes mit minimalen Aufwand (quasi automatisch) auf den aktuellen Stand gehalten werden können. Hierzu gibt es im Prinzip zwei Möglichkeiten.

  • Die Dokumentation wird aus dem Sourcecode automatisch generiert.
  • Die Dokumentation wird automatisch auf Konsistenz mit dem Sourcecode überprüft.

Ersteres lässt sich einfach mittels RDoc, Perldoc, JavaDoc und ähnlicher Werkzeuge erreichen. Kombiniert man hierbei den automatisch erstellten Teil mit Beschreibung, z.B. auf Paketebene, können sehr gute Dokumentationen entstehen. Daneben gibt es eine ganze Reihe von Tools, die eher zur Analyse als zur Dokumentation gedacht sind, wie z.B. JBoss Tattletale, aber dennoch eine guten Überblick über die Abhängigkeitsstruktur bieten. Die zweite Möglichkeit, also die Validierung der Dokumentation gegenüber der Implementierung, kann z.B. auf Ebene der Paket- und Abhängigkeitsdefinition durch Tools wie XRadar, Macker oder Dependometer realisiert werden. Die Architektur, d.h. Pakete und Abhängigkeiten einer Anwendung, werden dabei meist in Form einer XML-Konfigurationsdatei dokumentiert und vom Tool überprüft.

Unabhängig davon, wie genau in dem Projekt dokumentiert wird, muss die Aktualisierung der Dokumentation Bestandteil der Definition of Done sein. Damit ist sichergestellt, dass am Ende jeder Iteration Sourceode und Dokumentation auf einander abgestimmt sind. Wenn es dann noch gelingt, die notwendige Dokumentation automatisch zu erzeugen, fällt auch kein zusätzlicher Aufwand an.

Der vielleicht wichtigste Gedanke in diesem Zusammenhang ist, dass wir beim Erstellen der Software nicht so sehr an die Maschine denken, auf der das System später läuft, sondern an diejenigen, die später mit dem System arbeiten müssen. Und dazu gehören nicht nur die Anwender, sondern auch die Kollegen, die Wartung, Betrieb und Weiterentwicklung übernehmen.

 

 

Quelle Bild: © Cybrain – Fotolia.com

| Keine Kommentare

 
Top | Impressum