Software Aging Ein Erosionswächter für die Software muß her

Autor / Redakteur: Rainer Koschke* / Martina Hafner

Als Projektmanager und Software-Entwickler kann man mit der Zeit den Eindruck gewinnen, dass unsere kunstvoll gestaltete Software langsam zerbröckelt – sie erodiert unter unseren Händen und lässt sich immer schwerer ändern. Wie können wir unsere Software vor Erosion schützen?

Anbieter zum Thema

Manchmal kann man den Eindruck gewinnen, dass mit der Zeit an der so kunstvoll gestalteten Software einige Ecken und Kanten abgebröckelt seien. Zu Anfang ist eine Software ihren Aufgaben gewachsen. Ich kenne jedoch keine Software, deren Aufgabenstellung sich mit der Zeit nicht geändert oder ausgeweitet hätte. Die Software muss ständig an neue Kundenwünsche und an eine sich ändernde Umgebung angepasst werden. Zusammen mit der unvermeidlichen Fehlerbehebung fasst man diese Tätigkeit unter den Begriff der Software-Wartung zusammen.

Da kaum jemand anfängt, auf der grünen Wiese Software zu entwickeln, sind wir mehr oder weniger alle Wartungsentwickler. Meistens stehen wir dabei unter Zeitdruck. Unsere Aufgabe ist es, die uns anvertraute Software mit den uns zur Verfügung stehenden Ressourcen zu warten. Gemessen werden wir oft an der Zeitspanne, die wir brauchen, um neue Anforderungen für den Kunden umzusetzen. Dabei kann man auch beobachten, wer an unserer Software nagt: Es sind wir selbst, da nur wir aktiv Änderungen an der Software vornehmen.

Besonders wenn wir neu im Projekt sind und uns per Training-on-the-Job zurechtfinden müssen oder wenn wir, ganz profan, unter Projektdruck stehen. Hier ein wenig, dort ein bisschen. Tag ein, Tag aus. Unbemerkt, aber stetig. Irgendwann fällt auf, dass die Software im Innern erodiert ist. Die Qualität hat gelitten: zuerst die innere Qualität, die außer uns Entwicklern kaum jemand zur Kenntnis nimmt, später auch die äußere Qualität, die uns dann vorgeworfen wird. Dieser Effekt hat viele Namen bekommen: Software Aging, Software Decay, der vielleicht plastischste ist Software-Erosion.

Die Ersosionskräfte wider unsere Software sind vielgestaltig, so wie die Erosion in der Natur von Winderosion bis zum Frostaufbruch reicht: Verstöße gegen die Software-Architektur sind die gröbsten Schnitzer, Stilverstöße im Kleinen betreffen nur einzelne Zeilen im Quellcode.Es gibt per Copy&Paste duplizierte Quelltexte (sogenannte Klone), die wir synchron halten müssen und die zur schieren Größe der Software beitragen. Zyklen in der Abhängigkeit – z.B. zwischen unseren Quelldateien – und tote Teile in der Software sind ebenso beteiligt. Und schließlich degenerieren Teile durch ungebremstes Wachstum und ungezügelte Ad-Hoc-Änderungen.

Ein Erosionswächter für die Software muß her

Aber was können wir gegen uns selbst unternehmen? Wir können versuchen, diszipliniert zu arbeiten und beständig Reviews vorzunehmen. Hand aufs Herz: Wer kann das durchhalten? Sobald Termindruck aufgebaut wird, werden viele gute Vorsätze fallen gelassen, auch wider besseres Wissen. Also brauchen wir Unterstützung, so weit wie möglich automatisiert: Ein Erosionswächter für unsere Software muss her.

Die wichtigste Einsicht ist, dass unsere Software nicht über Nacht zerfällt, sondern einem langsamen Zerfallsprozess unterliegt. Der Zerfall kann auch nicht an einer einzelnen Aktion festgemacht werden. Vielmehr sind es die vielen kleinen Schritte, die uns jeder für sich vermutlich sogar Zeit gespart haben, in Zukunft aber dafür sehr viel mehr Zeit verschlingen werden. Wir haben durch unser Handeln eine Erosions-Hypothek auf unsere Software aufgenommen, die wir teuer zurück zahlen müssen.

Die notwendigen Maßnahmen sind also: Erosionsprozesse aufdecken, die einzelnen Schritte transparent machen und Gegenmaßnahmen ergreifen. Wer schon einmal ein Werkzeug genutzt hat, um Stilprüfungen durchzuführen oder Metriken zu erheben, der weiß, dass solche Werkzeuge lange Listen an Befunden auswerfen können. Einmal im Jahr angewandt hat es fast keinen Sinn, auf alle Befunde zu reagieren. Wenn wir ernsthaft gegen Software-Erosion vorgehen wollen, dann kommen noch Befunde über Klone, Architekturverstöße, zyklische Abhängigkeiten usw. dazu. Dadurch wird die Liste immer länger.

Also ist es sinnvoll, die Veränderungen zu beobachten. Unser Erosionswachhund muss mit dem Versionskontrollsystem gekoppelt sein, um Verläufe aufzeigen zu können und, besonders wichtig, Information über geänderte Stellen ausgeben zu können. An den Dingen, die von mir im letzten Monat unter Druck eingebaut werden „mussten“, kann ich, sobald wieder etwas mehr Luft ist, noch etwas ändern.

Natürlich darf dieses Erosionssicherheitsnetz kein Freifahrtschein für schludrige Arbeit sein. Es ist genau das, was es ist: eine Sicherheitsmaßnahme. So wie ein Lawinenzaun eine Sicherheitsmaßnahme ist und uns keinen Freibrief für die Rodung ganzer Bergwälder geben kann.

Wenn die Qualität einer Software im Vordergrund steht, kann mittels einer Erosionsüberwachung tagesaktuell nachgewiesen werden, dass innere Qualität vorhanden ist. Durch den Einsatz im Prozess kann die Qualität beständig auf einem hohen Niveau gehalten werden. Werden Refactoring-Aktivitäten notwendig, weil sich die Architektur anpassen muss, dann kann konsistent geprüft werden, ob sich die Software in die richtige Richtung entwickelt.

Wichtige Schritte im Kampf gegen erodierende Software

Wenn wir uns entscheiden, dass wir keine erodierte Software mehr haben wollen, dann sind folgende Schritte notwendig:

Wir müssen uns Unterstützung sichern: Die innere Qualität unserer Software muss „Chefsache“ sein. Wenn wir als Entwickler keinen Rückhalt haben, dann fallen unsere guten Vorsätze schnell über Bord. Besonders die Rollen im Projekt, die selbst keine Software entwickeln, aber über den Druck gebieten, müssen innere Qualität fordern und fördern. Und sie müssen verstehen, dass eine saubere und wartbare Software für sie langfristig vorteilhaft ist.

Oder negativ formuliert: Sie müssen verstehen, dass eine unwartbare weil erodierte Software gravierende Nachteile mit sich bringt. In der Analogie des Bergdorfes sind die Managementrollen der Gemeinderat des Bergdorfes, der seinen eigenen Schutzwald roden lässt.Wir müssen aber auch unsere eigene Einstellung überprüfen: An sich sind wir als Entwickler gefordert, unsere Arbeitsergebnisse so abzuliefern, dass sie unseren Ansprüchen an Qualität genügen.

Dazu gehört auch, dass wir uns zum Beispiel im Vorfeld über die Architektur Gedanken machen. Man könnte sagen, dass wir Software-Entwickler die Bewohner des Bergdorfes sind und, bislang unter dem Druck des Gemeinderates, unseren Schutzwald selbst roden. Sollten wir das wirklich wollen? Wir müssen unsere Sicherheitsmaßnahmen automatisieren: Per Hand durchgeführte Prüfungen fallen erfahrungsgemäß schnell über Bord, sobald sich Druck aufbaut.

Wir brauchen integrierte Sicherheitsmaßnahmen: Durch eine Integration mit dem Versionskontrollsystem lassen sich die Stellen finden, die noch ganz frisch erodiert sind. Erfahrungsgemäß lässt sich diese Stelle schnell säubern. Wir benötigen kontinuierliche Sicherheitsmaßnahmen. So wie Lob frisch serviert werden sollte, damit es noch perlt, so muss auch an die eigene Scham frisch appelliert werden. Dinge, die lang zurückliegen, sind kaum mehr der Rechtfertigung wert. Und inzwischen bauen bereits andere Teile der Software darauf auf. Es wird immer schwerer etwas zu tun, je länger die Erosion zurückliegt.

Wenn es uns gelingt, diese Punkte zu beherzigen, dann können wir uns und unsere Software vor der durch uns selbst erzeugten Software-Erosion schützen. Das lohnt sich langfristig immer und gibt uns die Zeit zurück, die wir brauchen, um unsere Software auch zukünftig voranzubringen. Denn eine Software, über die eine Lawine wegen mangelndem Erosionsschutz ungeschützt hereinbrechen konnte, taugt nur noch für die Planierraupe.

*Dr. Rainer Koschke ist Professor für Mathematik und Informatik an der Universität Bremen. Er ist einer der Gründer des Forschungsprojekts Bauhaus, das sich mit Programmanalysen für das Verstehen und die Weiterentwicklung großer, bereits existierender Programme auseinandersetzt.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:326052)