Legacy von Geburt an

Bad Code: Wie er entsteht – und wie er sich verhindern lässt

Nadine Riederer

© Shutterstock / BEST-BACKGROUNDS

Durch Nachlässigkeiten kann Software entstehen, die vom Start weg legacy ist. Eines der besten Mittel dagegen ist Kommunikation. Nadine Riederer, CEO bei Avision, erklärt in diesem Fachartikel, wie sogenannter „Bad Code“ entstehen kann und wie man ihn effektiv verhindert.

Gehen Entwicklungsabteilungen bei der Erstellung von Software nicht konsequent und diszipliniert vor, schaffen sie Bad Code. Sie produzieren Softwareanwendungen, die vom Start weg genauso aufwändig und teuer in der Pflege sind wie Legacy-Applikationen, ohne dass dafür erst viele Jahre ins Land ziehen müssen. Ihre Unternehmen kommt das teuer zu stehen.

Aufwändige Tests wegen undurchsichtiger Codestrukturen

Ein Garant für Bad Code sind undurchsichtige Programmstrukturen. Ganze Bibliotheken mit Methoden und Klassen, die wiederverwendet werden; Codeschnipsel, die mehrfach vererbt sind; und Services, die von möglichst vielen Programmteilen benutzt werden sollen. Das alles führt dazu, dass die Komponenten einer Software sehr stark aneinander gebunden sind. Wird dann eine dieser Komponenten verändert, ist nicht mehr nachvollziehbar, welche Auswirkungen das hat. Oft reicht es schon aus, in einer Bibliothek lediglich eine Basisklasse zu verändern, um unüberschaubare Effekte in einer Unmenge von Programmcode zu produzieren. Ergebnis: Die Entwickler müssen umfangreiche, aufwändige und kostspielige Tests durchführen, um die Folgen der Veränderung zu eruieren.

Aber nicht nur der Code selbst ist häufig ein Problem. Auch die eingesetzten Programmiersprachen, Betriebssysteme und Frameworks können aus einem eigentlich brandneuen Programm direkt Legacy-Software machen, wenn sie veraltet oder exotisch sind. Für den Einsatz solcher Produkte mag es zwar einen guten Grund geben: nämlich dass sie sich für den konkreten Einsatzzweck perfekt eignen. Die Folgen machen diesen Vorteil aber mehr als zunichte. Es gibt für veraltete oder exotische Programmiersprachen, Betriebssysteme und Frameworks schlichtweg nicht mehr genug Experten. Hat man einen davon im eigenen Haus, wird er das Unternehmen irgendwann verlassen – und mit ihm geht das exklusive Know-how. Einen adäquaten Ersatz zu finden ist dann oft unmöglich.

Support für die eingesetzten Komponenten nicht im Blick

Eine Nachlässigkeit, die in der Praxis ebenfalls immer wieder vorkommt: Die IT hat den langfristigen Support für Komponenten wie Frameworks, Betriebssysteme, Datenbanken oder Browser nicht im Blick. Teilweise setzen sie bei der Entwicklung einer neuen Software sogar Komponenten ein, für die das Ende des Supports von ihren Anbietern bereits offiziell angekündigt ist. In so einem Fall ist dann das aufwändige, kostspielige und riskante Migrationsprojekt bereits vorprogrammiert. Ein ganz ähnliches Problem kann auch aus dem Einsatz von Open-Source-Komponenten resultieren. Zwar spricht natürlich nichts dagegen, etwa ein freies Framework zu verwenden; ganz im Gegenteil, daraus ergeben sich zahlreiche Vorteile. Handelt es sich dabei allerdings um ein Framework, das keine breite und aktive Community im Rücken hat, besteht die große Gefahr, dass es irgendwann nicht mehr weiterentwickelt wird. Auch dann ist das künftige Migrationsprojekt schon von vornherein angelegt.

Ein häufiger Schlendrian bei der Softwareentwicklung ist außerdem die Vernachlässigung der Dokumentation. Sie kann ihren Zweck natürlich nur erfüllen, wenn sie immer auf dem neuesten Stand ist. Hinkt sie einige Releases oder Sprints hinterher, können sich Dritte nicht darauf verlassen, dass sie die technische Funktionsweise der Software korrekt wiedergibt. Sie sind dann immer gezwungen, im Code selbst nachzuschauen und es gibt keine Garantie dafür, dass sie dadurch die technische Funktionsweise der Software nachvollziehen können. Die Weiterentwicklung durch andere Programmierer oder Dienstleister wird damit erheblich aufwändiger und schwieriger.

Lose gekoppelter Code ist Good Code

Um die Entwicklung von Bad Code zu verhindern, ist eine der wichtigsten Aufgaben überhaupt, lose gekoppelten Code zu schreiben. Am besten werden seine Komponenten dabei nach fachlichen Kriterien gekapselt. Fällt irgendein fachlicher Aspekt weg oder muss verändert werden, ist dann genau ersichtlich, wo sich der nötige Codeabschnitt befindet. Die einzelnen Komponenten der Software sollten mit Schnittstellentechnologien wie Webservices miteinander kommunizieren. Muss eine Komponente verändert werden, hat das dann keinerlei Auswirkungen auf die übrigen davon.

Für die Erstellung und laufende Pflege der Dokumentation bieten moderne Entwicklungsumgebungen die Möglichkeit, sie aus dem Code heraus zu erzeugen. Die Entwickler dokumentieren dazu direkt im Code und die Dokumentation besteht dann aus dem Code an sich und den zugehörigen Erläuterungen der Programmierer. Die Voraussetzung dafür ist aber natürlich, dass die Entwickler die nötigen Kommentare auch wirklich in den Code einfügen. Sie müssen dabei nicht erläutern, was der Code macht: das ist am Code selbst erkennbar. Aber sie sollten erläutern, warum sie so und nicht anders programmiert haben, welche Entscheidungen sie warum getroffen haben und idealerweise auch, welche fachlichen Aspekte ihr Code abbildet. Dann lässt sich aus ihrem Code hervorragend eine Dokumentation erzeugen, die immer aktuell und nachvollziehbar ist.

Kommunikation als zentraler Erfolgsfaktor

Ein weiterer zentraler Erfolgsfaktor für Good Code ist die Kommunikation. Die Entwickler dürfen ihren Code nicht als ihren persönlichen Besitz betrachten, sondern als das, was er ist: Allgemeingut ihres Unternehmens. Sie dürfen sich nicht davor scheuen, mit anderen über ihren Code zu sprechen, ihn auch von ihren Kollegen anschauen zu lassen und komplizierte oder kritische Stellen sogar gemeinsam mit ihnen zu entwickeln; und findet jemand einen Fehler im Code eines anderen, sollte es auch kein Problem darstellen, wenn er ihn direkt beseitigt. Ganz so, wie es sich im Wissenschaftsbetrieb beim Peer Review bewährt. Durch eine solche Kultur der Offenheit und Kollegialität, bei der alle voneinander lernen, verbessert sich das Know-how der Programmierer, die Qualität der Software steigt und die gesamte Organisation kann sich weiterentwickeln.

Aber nicht nur der Austausch innerhalb der Entwicklungsteams ist wichtig. Auch die Kommunikation der Entwickler mit der Fachseite muss stimmen. Die Versuchung, mit den Kollegen aus den Fachabteilungen nicht allgemeinverständlich, sondern mit vielen Fachbegriffen über Software zu sprechen ist für Entwickler oft groß; schließlich können sie sich dadurch selbst einen Expertenstatus verschaffen. Beide Seiten müssen aber eine gemeinsame Sprache finden, um sich gegenseitig zu verstehen. Ansonsten besteht die Gefahr, dass etwas komplett Falsches programmiert wird – und davon hat am Ende dann keiner was.

Verwandte Themen:

Geschrieben von
Nadine Riederer

Nadine Riederer ist CEO bei Avision, einem auf Software Revival spezialisierten IT-Dienstleister in Oberhaching bei München.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: