Refactoring vs. Relaunch
IT ist ein Geschäftsfeld, das sich rasant verändert. Vor allem die Webtechnologien entwickeln sich in einem Tempo weiter, das lebenslanges Lernen zu einem Must anstatt zu einem Nice-to-Have macht. Umso erstaunlicher ist es, wenn man auf Berichte stößt, die älter sind als einige unserer Mitarbeitenden und Probleme beschreiben, die auch Jahre später noch genau so bestehen.
Es geht um diesen Artikel mit dem Titel "Things You Should Never Do", der als Timestamp den 6. April 2000 (!) trägt:
Zur zeitlichen Einordnung für alle, die noch vage Erinnerungen an diese Zeit haben: Er beginnt mit dem Satz „Netscape 6.0 is finally going into its first public beta“. Im selben Absatz kommt der Satz „Three years is an awfully long time in the Internet world.“ vor. Der Artikel ist 23 Jahre alt (das sind ungefähr 300 in Web-Jahren) und es klingt alles schrecklich, schrecklich vertraut.
Der Traum, alles besser zu machen
Der Autor, Joel Spolsky, berichtet von einem strategischen Fehler, den Netscape (für die Jüngeren unter uns: Der Netscape Navigator war ein zeitweise sehr weit verbreiteter Browser) damals begangen hatte: Sie hatten entschieden, den Code für den Browser von Grund auf neu zu schreiben. Diese Entscheidung hatte dazu geführt, dass Netscape drei Jahre lang keinen neuen Major Release veröffentlichen konnte und von Version 4 direkt auf Version 6.0 springen musste.
Netscape ist nicht die erste Software, die sich in so einer Entscheidung verrannt hat und sie wird nicht die letzte sein. Spolsky sieht das Problem an einigen Grundeigenschaften der Programmierung und jenen, die sie durchführen:
„We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.
There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.“
Kill it with fire!
Jede*r Entwickler*in kennt es: Die Reaktion auf den Erstkontakt mit dem Code eines lange bestehenden, wiederholt geflickten und beständig weiterentwickelten Projektes ist: Kill it with fire! Platt machen, neu machen. Relaunch.
Spolsky sieht hierin einen großen Fehler: Verwirft man den kompletten Code eines Projekts, gehen die Bugfixes, Patches und Edge-Case-Umgehungen von Jahren verloren und oft ist der Neubau zunächst instabiler und, na ja, schlechter, als die scheinbar unrettbare Vollkatastrophe von zuvor.
Er plädiert eher für Code-Pflege als für den Radikalschnitt: Refactoring, Debugging, Vereinheitlichung. Nicht die schönsten Aufgaben in der Programmierung, aber die, die die Langlebigkeit eines Projektes deutlich erhöhen. Kunden sollten das gerade in großen, komplexen Software-Projekten daher immer auch als lohnende, regelmäßig anfallende Aufgabe auf dem Schirm haben.
Websites sind keine Browser
Ein Kahlschlag mit geordnetem, strukturiertem Neubau ist bei Websites im Gegensatz zu Browsern, die unter ganz anderen Bedingungen funktionieren müssen, trotzdem von Zeit zu Zeit notwendig. Oft diktieren Sicherheitslücken alter Abhängigkeiten oder technologische Sackgassen der alten Code-Basis einen Neuanfang: Use-Cases und Usergewohnheiten verändern sich und lassen sich oft mit alter Software nicht oder nur mit sehr viel unnötigem Aufwand abbilden. Und als Faustregel lässt sich sagen: Je länger man damit wartet, Projekte zu verjüngen, desto schwieriger wird die Migration letztendlich.
Insbesondere bei Projekten, die stark auf der Nutzung anderer Software basieren, wie das im Web meistens der Fall ist, ist es wichtig, die zugrundeliegende Software aktuell zu halten: Javascript-Bibliotheken und -Frameworks auf dem neusten Stand zu bringen, Python-Versionen, Server-Betriebssystem, Sicherheitsupdates und neue Releases von Content Management Systemen – wer da nicht mitzieht, gerät in kürzester Zeit in Teufels Küche.
Zudem bringt der Relaunch einer Website oft große Vorteile: Gesteigerte Performance, bessere Sicherheits-Features, mehr Funktionalität, bessere Usability – oft sogar weniger Aufwand bei Wartung und neuen Feature-Wünschen! Nur bei extrem großen und vielgenutzten Seiten (wie zum Beispiel Social Media Sites), die astronomische Anforderungen an Performance, Skalierbarkeit und Verfügbarkeit haben, mögen die Vorteile der inkrementellen Weiterentwicklung überwiegen. Bei den allermeisten Seiten lohnt es sich, in regelmäßigen Intervallen technologischen Ballast abzustoßen und die Seite in Design, Code-Basis und Usability neu aufzusetzen.
Nicht verschwenden, wiederverwenden!
Wichtig ist jedoch die Einsicht: In der Regel hat jede Zeile Code eine Geschichte und einen guten Grund, weswegen sie da ist. Selbst wenn man ein Projekt neu aufsetzt, ist der erste Schritt, sich den alten Code anzusehen und sich zu fragen:
- Welche Probleme wurden hier wie gelöst? Welche Fehler und Grenzfälle abgefangen, die erst im Einsatz unter Realbedingungen aufgefallen sind?
- Was können wir aus dem Zustand des Legacy Systems lernen? Vielleicht können Funktionen oder Problemlösungen in das neue System integriert werden?
- Welche Faktoren im Projektablauf haben zu suboptimalen Lösungen geführt? Herrschte Zeitdruck? Wurden nachträgliche Feature-Requests an die ursprüngliche Architektur angeflanscht? Wie lassen sich unschöne Quick-and-Dirty-Lösungen und Feature-Wucherungen vermeiden?
Aus der Vergangenheit zu lernen, muss nicht heißen, sie permanent mit sich herumzuschleppen. Eine Website ist kein Browser oder Betriebssystem oder ein vergleichbarer Software-Monolith und profitiert nach ein paar Jahren in den allermeisten Fällen von einem strukturierten, gut konzipierten Relaunch.