Ein Angebot von

Software-Wartbarkeit trotz Erosion

| Autor / Redakteur: Rainer Koschke und Thomas Eisenbarth * / Sebastian Gerstl

Software-Wartbarkeit trotz Erosion: So wie Wind und Regen Gestein zur Erosion führen, wirken unter Zeitdruck ausgeführte Entwicklungsschritte erosiv auf die inneren Strukturen einer Software.
Software-Wartbarkeit trotz Erosion: So wie Wind und Regen Gestein zur Erosion führen, wirken unter Zeitdruck ausgeführte Entwicklungsschritte erosiv auf die inneren Strukturen einer Software. (Bild: Dimitris Vetsikas auf Pixabay / Pixabay)

Alle wünschen sich eine hohe Software-Wartbarkeit. Mit Software-Erosionsschutz lässt sich dieses Ziel trotz widriger Rahmenbedingungen in der Praxis erreichen.

Eine hohe Reaktionsgeschwindigkeit der Software-Entwicklung ist wettbewerbsentscheidend. Kunden- und Marktanforderungen ändern sich immer schneller, Innovationen werden zunehmend durch Software realisiert, die Abkündigung von Bauteilen erzwingt Anpassungen an der Software und die geforderte Variantenvielfalt nimmt zu. Um die hierfür notwendige hohe Reaktionsgeschwindigkeit zu erreichen, ist eine exzellente Software-Wartbarkeit zwingende Voraussetzung.

Trotzdem ist Wartbarkeit oft keine klar umrissene Zielvorgabe, sondern eine diffuse Forderung, da Wartbarkeit eine innere Qualität der Software ist, die sich nicht in den funktionalen Anforderungen des Kunden widerspiegelt. Im Tagesgeschäft wird die Wichtigkeit der Wartbarkeit als Wettbewerbsfaktor daher oftmals unterschätzt. Aufgrund des Zeitdrucks und der sich häufig ändernden Anforderungen werden Vorgaben der Software-Architektur nicht durchgängig eingehalten, es wird per Copy and Paste programmiert und nicht mehr benötigte Teile werden nicht entfernt.

Wartbarkeit und Erosion von Software: Ein ganzheitliches Qualitätsverständnis

Diesen steten Zerfall der inneren Struktur eines Software-Systems bezeichnet man als Software-Erosion. Die schlechter werdende Wartbarkeit verschärft bereits bestehenden Zeitdruck zusätzlich, so dass immer weniger Zeit bleibt, den Erosionsprozess aufzuhalten. Der Erosionsprozess verstärkt sich selbst. Wie lässt sich dieser Teufelskreis durchbrechen? Damit der Durchbruch erfolgreich und mit überschaubarem Aufwand gelingt, müssen drei wesentliche Punkte berücksichtigt werden, die im Folgenden aufgezeigt werden.

Intuitiv wissen alle Beteiligten, vom Software-Entwickler bis zum Manager, dass Software-Wartbarkeit essentiell für die Wettbewerbsfähigkeit ist. Das Problem im Tagesgeschäft ist ein anderes. Der Aufwand von allen Beteiligten wird systematisch überschätzt und der mögliche Nutzen systematisch unterschätzt. Hinzu kommt, dass es sehr oft Kommunikationsprobleme und Missverständnisse zwischen der Entwicklung und dem technikfernen Management gibt.

Der Entwickler denkt, es komme ausschließlich auf die Umsetzung der funktionalen Anforderungen an, der Manager hingegen denkt, Wartbarkeit bedeute zwangsläufig aufwändige Refactoring-Maßnahmen. Software-Erosionsschutz beginnt folgerichtig damit, ein Bewusstsein für Software-Wartbarkeit zu schaffen, und zwar bei allen Beteiligten. Für das Management bedeutet das, dass es sich auf konkrete, messbare und erreichbare Zielvorgaben für die Wartbarkeit festlegen muss. Diese müssen denselben Stellenwert bekommen wie bereits bestehende Zielvorgaben.

Dem Entwickler müssen neben den Zielvorgaben bezüglich der Wartbarkeit auch die positiven Effekte bewusst gemacht werden. Denn erosives Entwickeln kann dem Entwickler kurzfristig Zeit einsparen. Hier ist das Verständnis wichtig, dass kurzfristige Quick-Wins langfristigen Wartbarkeitszielen entgegenwirken. Mit einem guten Schulungskonzept lässt sich dieses Bewusstsein mit einer halbtägigen Schulung schaffen. Die Kommunikation eines ganzheitlichen Qualitätsverständnisses muss integraler Bestandteil bei der Einarbeitung neuer Mitarbeiter sein.

Vorgaben für die Softwarewartung klar definieren

Software-Erosion stoppen: Der Effekt der Erosion ist, dass immer mehr Zeit für das Verstehen bestehender Software aufgewendet werden muss
Software-Erosion stoppen: Der Effekt der Erosion ist, dass immer mehr Zeit für das Verstehen bestehender Software aufgewendet werden muss ( Axivion)

Aus der diffusen Forderung nach Wartbarkeit müssen in jedem Fall klar formulierte und im Tagesgeschäft erreichbare Zielvorgaben abgeleitet werden. Dazu muss eine Standortbestimmung auf Basis bestehender Projekte vorgenommen werden. Stärken und Schwächen bezüglich der Wartbarkeit werden ermittelt.

Kern der Standortbestimmung ist die Betrachtung der Architektur. Denn eine tragfähige, flexible und erosionsfrei implementierte Architektur ist die Grundlage für eine nachhaltig hohe Software-Wartbarkeit. Außerdem werden die Klonrate, Ausreißer, Verstöße gegen Codierrichtlinien, toter Code und zyklische Abhängigkeiten ermittelt. Die Standortbestimmung bestätigt oft die Vermutungen der beteiligten Entwickler. Diese Objektivierung des Bauchgefühls ist eine gute Grundlage, um faktenbasiert, abteilungs- und hierarchieübergreifend den Status Quo zu bewerten und erreichbare Ziele bezüglich der Wartbarkeit festzulegen.

Eine nüchterne Herangehensweise nimmt der Diskussion über Wartbarkeit und Code-Qualität die oftmals vorhandene und behindernde Emotionalität. Wichtig ist, dass es nicht um Schuldzuweisungen für Vergangenes geht, sondern um Lehren für die Zukunft.

Ein objektiver Dritter sollte mit einbezogen werden, der bezüglich des Projekts unabhängig ist und allein schon deswegen sehr gut vermitteln kann. Optimal ist es, wenn dieser auch bei der Umsetzung der Maßnahmen unterstützen kann. Basierend auf den Erkenntnissen wird dann festgelegt, welche konkreten Erosionsverursacher gemessen werden. Das generelle Ziel lautet, bezüglich der Erosionsverursacher auf alle Fälle nicht schlechter zu werden. Herauszufinden, in welchen Teilbereichen und Arbeitspaketen mit vertretbarem Aufwand Verbesserungen erreicht werden können, ist Teil des Fokussierungsprozesses.

Ressourcen effektiv und effizient einsetzen

Exponentiell steigende Komplexität: Das führt zu einem ebenso stark steigenden Zeitbedarf für die Implementierung neuer Funktionalität
Exponentiell steigende Komplexität: Das führt zu einem ebenso stark steigenden Zeitbedarf für die Implementierung neuer Funktionalität ( Axivion)

Bewusstsein und klare Zielvorgaben sind ein erster wichtiger Schritt. Im Tagesgeschäft ist es nun entscheidend, effizient mit den vorhandenen Ressourcen, vor allem der Arbeitszeit der Entwickler, umzugehen. Eine erste wichtige Entlastung der Entwickler schafft eine vollständige Automatisierung der Erosionsüberwachung. Die Maßnahmen gegen Software-Erosion müssen auf die gewinnbringenden Stellen fokussiert werden. Je nach Lage in den einzelnen Systemteilen kann man mit einer Portfolio-Analyse zwischen verschiedenen Modi situativ auswählen und damit Ressourcen noch weiter fokussieren.

Automatisierte Prüfungen anstelle manueller Reviews

Die meisten Erosionsverursacher sind ihrem Wesen nach nicht lokal begrenzt. Die Kenntnis einer Codestelle oder eines Dokuments allein reicht dann nicht aus, die Erosion zu entdecken. Wichtig ist, den gesamten Quellcode zu betrachten, denn er offenbart Klone, toten Code, Zyklen und Architekturverstöße. Auch viele Metriken und Stilverstöße lassen sich erst im Zusammenhang des gesamten Codes ermitteln.

Mit herkömmlichen Testmethoden lässt sich Software-Erosion ebenfalls nicht nachweisen. Ein Test sagt nichts über die innere Qualität aus. Die innere Software-Qualität muss nicht nur sporadisch, sondern kontinuierlich gemessen werden. Denn werden sofort Maßnahmen gegen Erosion ergriffen, setzt sich die Erosion nicht in der Software fest. Um die Wartbarkeit einschätzen zu können, sind sowohl Expertenmeinungen als auch automatisierte Analysen der Code-Qualität notwendig. Hierbei kommen dieselben Analysen wie für den begleitenden Erosionsschutz zum Einsatz. Je nach Quadrant fallen die strategisch sinnvollen Maßnahmen unterschiedlich aus. So gibt es die Wahl zwischen:

  • einem Hygienemodus für Neubau-Code,
  • einem Continuous Refactoring für leicht erodierten Altbau-Code,
  • gezieltem Refactoring für wirtschaftlich wichtigen Altbau-Code,
  • und schließlich Wrapping-Maßnahmen für technisch hoffnungslosen, jedoch wirtschaftlich wichtigen Code.

Gezielter Ressourceneinsatz durch strategisches Vorgehen

Innerhalb der in der Portfolio-Analyse identifizierten Projekte können nun wiederum Ressourcen fokussiert werden. Betrachten wir den Fall eines Systems, für das die Portfolio-Analyse den entwicklungsbegleitenden Erosionsschutz als adäquat identifiziert hat. Diese Maßnahme zielt darauf ab, auf alle Fälle das Niveau der inneren Software-Qualität zu halten und darüber hinaus aus der Situation heraus lokal zu verbessern. Da man bei der Analyse der inneren Software-Qualität regelmäßig mit Altlasten konfrontiert wird, ist eine Delta-Analyse notwendig, um bestehende Erosion von neuer Erosion unterscheiden zu können. Die Delta-Analyse ist ein wesentlicher Bestandteil jeder Lösung gegen Software-Erosion, denn gegen neue Erosion muss für einen entwicklungsbegleitenden Erosionsschutz sofort vorgegangen werden.

Ergänzendes zum Thema
 
„Software-Erosion schwächt die Wettbewerbsfähigkeit des Unternehmens“ – Ein Interview mit Sebastian Rummler, Managing Director bei Axivion

Was bei Altlasten im Quellcode zu tun ist

Altlasten können zunächst toleriert, müssen jedoch aufgeräumt werden, sobald die Entwicklungstätigkeit in einem erodierten Bereich zunimmt. Gegen Altlasten vorzugehen, erfordert also eine bewusste Entscheidung. In manchen Fällen ist sie einfach: Wenn beispielsweise gegen eine simple Stilregel verstoßen wurde, dann ist es in der Regel einfach, den Verstoß „im Vorbeigehen“ zu beheben.

In anderen Fällen, wie bei einem tief ins System verwobenen Architekturverstoß, ist eine schnelle und offensichtliche Korrektur in der Regel nicht vorhanden und eine Planung muss angestoßen werden. Im Planungsprozess muss abgewogen werden, ob sich die Verbesserung rechnet und wie eine geeignete Refactoring-Maßnahme beschaffen sein muss. Die Beteiligten haben durch die geschaffene Transparenz das für die Abwägung notwendige Wissen über die Architektur und ihre Verstöße zur Hand.

Dadurch werden gleichzeitig Überraschungen, die in der Regel bei ad-hoc geplanten Anpassungen auftreten, minimiert: Man weiß vor dem eigentlichen Entwurf und seiner Detail-Implementierung, dass man sich in unübersichtliche Teile der Software vorwagt und wo sich Fallgruben in Form von Architekturverstößen befinden.

Diesen Ansatz nennt man Continuous Refactoring. Dadurch wird sukzessive die Qualität in den relevanten Bereichen der Software angehoben, spätere Änderungen in diesen Bereichen profitieren enorm von den Aufräummaßnahmen.

Fazit: Erosionsverursacher lassen sich direkt aufspüren

Es zeigt sich, dass nicht nur der Wettbewerbsvorteil wartbarer Software unterschätzt, sondern der Aufwand, der für wartbare Software notwendig ist, überschätzt wird. Hohe innere Software-Qualität und eine erosionsfreie Software-Entwicklung sind erreichbare Ziele, wenn wesentliche Dinge berücksichtigt werden. Ein gemeinsames Verständnis und Bewusstsein für die Wichtigkeit der Wartbarkeit von Software sind ebenso entscheidend wie die Einführung automatisierter Analysen und die Fokussierung der Ressourcen durch kontinuierliches Abwägen und Dosieren der Maßnahmen im Tagesgeschäft.

Ein System entwicklungsbegleitend wartbar zu halten, ist einfacher und effizienter, als es im Nachhinein oder in regelmäßigen Intervallen („Refactoring-Projekte“) wieder wartbar zu machen. Automatisierte Analysen helfen, die Erosionsverursacher direkt aufspüren und sofort Maßnahmen einzuleiten. Aufwände sind effizient und risikoarm verteilt, eben entwicklungsbegleitend, und bringen sofort Lerneffekte und positive Auswirkungen für den gesamten Entwicklungsprozess.

Alptraum Legacy Code – Wie Profis damit umgehen

Alptraum Legacy Code – Wie Profis damit umgehen

18.02.19 - Legacy Code bringt oft gewaltige Probleme bei der Entwicklung neuer Features mit: Variablen tragen nichtssagende Namen, Methoden sind zu überkomplexen Konstrukten mutiert und automatisierte Tests sind meist wenig bis gar nicht vorhanden. Wie geht man damit um? lesen

* Prof. Dr. Rainer Koschke ist Leiter der Arbeitsgruppe Softwaretechnik an der Universität Bremen. Thomas Eisenbarth ist Mitgründer und technischer Geschäftsführer bei Axivion in Stuttgart.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45887582 / Test & Qualität)