Vorsicht vor der Bolognese

Die Gefahren des Spaghetti-Code

Natali Vlatko

Was kann passieren, wenn man sich auf sogenannten „Spaghetti-Code“ einlassen muss, um betriebsnotwendige Systeme am Laufen zu halten? Wir werfen einen Blick auf Toyotas Spaghetti-Code-Debakel und sehen uns an, wie die schlechten Angewohnheiten von Programmierern als vererbter Code den Kern des Problems ausmachen.

Der Begriff „Spaghetti-Code“ jagt nahezu jedem Entwickler ein kalten Schauder über den Rücken. Von Natur aus verschlungen und komplex, wird er oft als unpflegbar, unstrukturiert, unmöglich zu debuggen beschrieben. Doch wie genau definiert sich „Spaghetti-Code“?

Wie Michael O. Church ausführt, ist Spaghetti-Code ein besonders klarer, aber sehr spezifischer Fall von schlechtem Code und nicht mit den Merkmalen von schlechtem Code im Allgemeinen in einen Topf zu werfen. Für Church ist klar, dass an diesem spezifischen Problemfall viel über Software-Entwicklung zu lernen ist, insofern Spaghetti-Code kaum von einzelnen Personen alleine geschrieben wird.

„Certain styles of development process make it increasingly common as time passes”.

An Beispielen für den Spaghetti-Code-Albtraum fehlt es nicht im World Wide Web. Häufig geben hier Entwickler ihre Erfahrungen mit dem verdorbenen Quellcode eines Unternehmens zum Besten. Einer der meistbeachteten Fälle betrifft den Autohersteller Toyota, dessen Verfehlungen im Standardverfahren erst vor Gericht bekannt wurden.

2013 wurde Toyota des grob fahrlässigen Handelns für schuldig befunden, in einem Gerichtsentscheid, der die unbeabsichtigte Beschleunigung eines seiner Fahrzeuge zum Gegenstand hatte. Der Fall ging auf den Tod von Barbara Schwarz sowie auf die schwere Verletzung von Jean Bookout zurück, die auf einem Interstate Highway in Oklahoma die Kontrolle über ihren 2005er Camry verloren hatte.

Während des Prozesses sagten die Software-Experten Philip Koopman und Michael Barr vor Gericht aus, nachdem sie die Praxis der Software-Entwicklung bei Toyota sowie den Quellcode untersucht hatten. Diesen bezeichneten sie in ihrer Aussage als „Spaghetti-artig“. Koopman, ein Spezialist für sicherheitskritisch eingebettete Systeme und Verfasser des unumstrittenen Standardwerks zum Embedded-System-Design, hat als Professor für Computer Engineering an der Carnegie Mellon University mehr als 125 Design-Prüfungen von eingebetteten Systemen in der Industrie durchgeführt.

Barr, ebenso Spezialist für Embedded Systems, verbrachte fast zwei Jahre mit der Prüfung von Toyotas Quellcode unter schwierigen Sicherheitsbedingungen und erstellte einen 800-seitigen Bericht, der ohne jeden Vorbehalt die Sicherheitsmängel in Toyotas Engineering-Prozess anprangerte. Seine und Koopmans Zeugenaussagen galten als der letzte Tropfen, der das Fass bezüglich des Zustands von Toyotas Computer-Engineering-Praxis zum Überlaufen brachte.

Wie Michael Dunn berichtete, ließ sich die grundsätzliche Kritik an Toyota auf folgende Punkte herunterbrechen:

  • Der Quellcode für Toyotas elektronisches Gaspedal-Kontrollsystem (ETCS) war von äußerst schlechter Qualität
  • Toyotas Quellcode war anfällig und enthielt Bugs, eingeschlossen derjenigen, die zu der unbeabsichtigten Beschleunigung führten
  • Die Metriken zur Code-Qualität ließen auf das Vorhandensein weiterer Bugs schließen
  • Toyotas Ausfallsicherheiten waren fehlerhaft und ungeeignet (die Rede war von einer Sicherheitsarchitektur wie der eines Kartenhauses)
  • Das Fehlverhalten von Toyotas ETCS war der Grund für die ungewollte Beschleunigung

Ebenso wurde darüber befunden, dass hier die eigenen Code-Standards gebrochen worden waren, die Toyota selbst etwas über dem Industrie-Standard angesetzt hatte. Im Bericht zur Sicherheitsforschung und Sicherheitsstrategie dokumentierte das Gutachten von Koopman und Barr Fehler im Design-Prozess, die in Toyatas Software-Modell praktisch eingebaut waren, einschließlich des Fehlens einer Peer Code Review.

Church’s Definition von Spaghetti-Code berührt neben anderen Fehlern, die in der Praxis auftauchen können, genau diesen Punkt:

Spaghetti code is evil because:
(a) it’s a very common subcase of bad code,
(b) it’s almost impossible to fix without causing changes in functionality, which will be treated as breakage if people depend on the old behaviour and
(c) it seems, for reasons I’ll get to later, not to be preventable through typical review processes.

Diese Gründe beziehen sich auf den inkrementell gebildeten Spaghetti-Code. Dieser macht es sehr schwer, seine problematischen Eigenschaften in einer Code Review einzufangen, insofern jede Änderung, die eine „Spaghettifizierung“ nach sich zieht, nach Church zunächst positive Auswirkungen auf den Geschäftsprozess zu haben scheint.

Während eine inkrementelle Prüfung des Codes zur Aufdeckung von offensichtlich schlechten Coding-Praktiken bestens geeignet ist, gilt das nicht für die Formausdehnung des Spaghetti-Code. In diesem Fall ist eine Prüfung des Gesamtprogramms von Nöten, auch wenn vermutlich kaum ein Betrieb einer solch groß-skalierten Prüfungsoperation zustimmen dürfte. Mit Witz betont Church an dieser Stelle, dass eine solche Praxis über einen langen Zeitraum so gut wie unmöglich ist, wenn nicht in Teams, die life- oder mission-critical Software schreiben, ein hohes Maß an Disziplin garantiert werden kann.

Für einen einzelnen Entwickler, der es mit Spaghetti-Code zu tun bekommt, wäre die Einwilligung in eine solche Code-Review entmutigend und nahezu aussichtslos. Dennoch, sehr oft sind die Beiträge zu Legacy Code, der möglicherweise einem Spaghetti-Code gleich kommt, von uns selbst und nicht von Anderen geschrieben, wie Arialdo Martini hervorhebt:

There isn’t a single person who is responsible for the whole mess. The bad programmer, the Legacy Code Writer, is a fictional character we invented to justify our little, continuous, sins. I came to the conclusion that writing Legacy Code is a distributed activity. Each of us contribute, eventually not intentionally, to this crowded, incessant, slow process. Don’t waste your time trying to seek him: we are that programmer.

Aber das Problem ist weitaus größer, als dass es nur die Programmierer selbst beträfe. Es müssen Prozesse in Gang gesetzt werden, um zu verhindern, dass Spaghetti-Code formbestimmend werden kann. Entwickler sollten nicht in die Falle tappen, andere dafür verantwortlich zu machen, dass er selbst unter seinen Möglichkeiten programmiert, nach dem Motto: „Ist nicht mein Fehler. Ich kann das so machen, ist ja der Fehler des Legacy-Code-Schreibers”:

The problem with particles of Legacy Code is that they are like gems of corals: they tend to attract other bad code, and they soon become as hard as hell to remove. Introduce a temporary variable, and be sure that the next programmer will feel justified to attach some code to it.

Spaghetti-Code, so fast Church zusammen, ist ein Nebenprodukt der Industrie-Programmierung, das oft ein Ergebnis des Umstands ist, dass ein Code durch zu viele Hände gegangen ist. Anders als das Problem von nicht mehr pflegbarem Code und beliebigen Programmfehlern ist Spaghetti-Code auch wegen des Verhaltens gefährlich, das Entwickler im Umgang mit ihm entwickeln.

Wie können wir dieses Aufstauen von schlechten Verhaltensweisen überwinden? Muss da etwas vom Management kommen oder gibt es Wege für Entwickler, um den Schaden selbst zu beheben?

Aufmacherbild: Spaghetti and Meatball von Shutterstock.com / Urheberrecht: graphicgeoff

Geschrieben von
Natali Vlatko
Natali Vlatko
An Australian who now calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for JAXenter.com (S&S Media Group).
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: