Sergey Nivens - Fotolia
Spaghetticode und andere Programmier-Anti-Patterns
Entwickler müssen versuchen, pflegeleichten, wiederverwendbaren Code zu schreiben. Softwareentwickler sind sich dabei einig, wie wartbarer Code nicht aussieht: wie Pasta.
Niemand hat je behauptet, dass es einfach ist, sauberen Code zu schreiben. Bei einer erfolgreichen Softwareentwicklung geht es nicht nur darum, dass die Software funktioniert, sondern auch darum, dass sie weiterhin funktioniert. Das ist zwar kein besonders aufregendes Ziel, aber die Wartbarkeit von Code ist eines der wichtigsten Elemente jeder Anwendung.
Wie sieht also wartbarer Code aus? Auf diese Frage gibt es keine allgemeingültige Antwort. Jede Sprache, jedes Framework und jedes Unternehmen verfolgt eine andere Strategie, um dauerhaften, wartbaren Code zu gewährleisten. Entwickler sollten die Gründe verstehen, warum Code nicht wartbar ist, um Programmierfehler zu vermeiden.
Nahezu alle Softwareentwickler sind sich einig, wie wartbarer Code nicht aussieht: wie Pasta. Die Pasta-Theorie der Programmierung, bei der verschiedene Arten von nicht wartbarem Code vertraute Formen und Strukturen von Lebensmitteln annehmen, ist eine Liste vermeidbarer Praktiken.
Die bekanntesten auf dieser Liste sind Spaghetticode, Lasagnecode, Raviolicode und Pizzacode. Hier finden Sie Beispiele für jedes dieser Anti-Patterns und wie sie sich in Software manifestieren.
Spaghetticode
Der Begriff Spaghetticode stammt aus den 1970er Jahren und ist eine Metapher für schlampigen, nicht wartbaren Code. Spaghetticode leitet seine Bedeutung von dem Wirrwarr einzelner Stränge ab, die eine Schüssel Spaghetti charakterisieren.
Älterer Code enthält fast immer Teile von Spaghetticode. In vielen Fällen war die Codebasis von Anfang an so. Unmittelbare Bedürfnisse bestimmen die Richtung von Projekten in ihren frühen Phasen. Dieser Druck führt dazu, dass Entwickler unter engen Zeitvorgaben und begrenzten Budgets arbeiten. Für Start-up-Unternehmen ist es ein Luxus, weit vorauszudenken, insbesondere wenn sie Mittel beschaffen und Kunden beeindrucken müssen. Was zählt, ist ein funktionierendes Produkt. Daher überdauern technische Machbarkeitsstudien ihre vorgesehene Lebensdauer bei Weitem und bereiten später Probleme.
Programmierer können mit etwas Übung lernen, wie man Spaghetticode vermeidet. Konzentrieren Sie sich auf die Trennung von Aufgaben und Prozessen. Jeder Codeabschnitt sollte einen logischen Ablauf haben. Isolierte Funktionssätze sollten abstrahiert werden, um sicherzustellen, dass jede Funktion und Klasse nur eine Aufgabe erfüllt – und diese gut. Und nehmen Sie sich die Zeit, den Code zu strukturieren. Spaghetticode entsteht oft durch kurze Fristen und mangelnde Planung.
Lasagnecode
Unachtsamkeit ist nicht der einzige Weg, um schwer zu pflegenden Code zu erhalten; auch Überkompliziertheit kann eine Ursache sein. Ein Beispiel ist ein Technologieunternehmen, das eine der verwirrendsten Codebasen hatte, die man je gesehen hatte. Jedes Element des Produkts war in Dutzende einzelner, verschachtelter Komponenten abstrahiert. Es war fast unmöglich, eine Änderung in einer Schicht des Stacks vorzunehmen, ohne jede andere Schicht zu beeinflussen. Die Codebasis war zwar nicht chaotisch, aber auch nicht wartbar.
Wenn Spaghetticode unter architektonischer Schlampigkeit leidet, ist Lasagnecode ein Merkmal von Over-Engineering in seiner extremen Form. Programmierer, die mit objektorientierten Codebasen arbeiten, tappen oft in diese Falle. Lasagnecode besteht aus abstrahierten, eng miteinander verbundenen Schichten; Entwickler schreiben ihn in der Überzeugung, dass jede Unterkomponente ein eigenes Objekt erfordert. Diese Programmierer neigen dazu, sich auf das Layout des Codes zu konzentrieren, was auf Kosten seiner Wartbarkeit geht. Was als hochgradig organisierte Codebasis beginnt, wird schnell zu einem Desaster mit zu vielen Strukturen.
Hier ist eine gute Regel, die man befolgen sollte: Gehen Sie bei Ihren Abstraktionen konservativ vor. Wenn Sie vorhaben, eine Komponente zu abstrahieren, die nur von einer anderen Komponente verwendet wird, die wiederum nur von einer einzigen anderen Komponente verwendet wird, sind Sie zu weit gegangen. Halten Sie die Codebasis einfach.
Raviolicode
Wie andere Ansätze in der Anwendungsarchitektur – monolithisch, serviceorientiert – weder von Natur aus gut noch schlecht sind, ist Raviolicode ein Designmuster, das zwar die richtige Idee hat, aber schnell aus dem Ruder laufen kann.
Raviolicode ist eine Metapher für kleine, in sich geschlossene Codeklassen, die einzelnen Nudelstücken ähneln. Raviolicode betont einen komponentenbasierten Codestil und fördert die Trennung von Anliegen. Diese Vorgehensweise ist ein guter Anfang für lesbaren, wartbaren Code, da eine Raviolicodebasis gut strukturiert ist. Jede Komponente ist von externen Abhängigkeiten isoliert, was Schritte wie Testen und Validieren erleichtert.
Allerdings gibt es, genau wie bei Lasagnecode, auch zu viel Abstraktion. Wenn Entwickler den Code extrem abstrahieren, können die individualisierten Komponenten den Anrufstapel einer Codebasis drastisch vergrößern. Raviolicode erschwert daher die langfristige Wartbarkeit. Finden Sie also ein Gleichgewicht; wenn Codeklassen besonders anämisch werden, ist es Zeit, sich zurückzuziehen.
Pizzacode
Pizza ist keine Nudelsorte, aber sie passt zusammen mit Spaghetticode und Ähnlichen in die Pastatheorie als Programmier-Anti-Pattern. In den meisten Fällen wird Pizzacode als Code mit einer flachen Architektur beschrieben.
Pizzacode hat im Allgemeinen eine große Anzahl von Klassen oder Funktionen, die alle auf derselben Ebene über einer grundlegenden Schicht miteinander verbunden sind. Im Pizzacode sind die einzelnen Komponenten im Allgemeinen unabhängig voneinander, aber es kann manchmal schwierig sein, eine davon zu entfernen, ohne andere zu beeinträchtigen.
Jede gute Software erfordert eine Struktur. Pizzacode leidet unter einem unzureichenden Design. Es ist gut, relativ isolierte Komponenten zu haben, aber Pizzacode macht es fast unmöglich, die Rollen und Verantwortlichkeiten der einzelnen Klassen zu verstehen. Um die Codebasis in den Griff zu bekommen, schneiden Sie den Pizzacode in Scheiben und fügen Sie jeder Komponente eine logische Struktur hinzu.
Andere Programmier-Anti-Patterns
Entwickler neigen dazu, mit italienischen Speisen als Metaphern für Designmuster zu übertreiben. Sie können Verweise auf zahlreiche Begriffe finden, die in die Parameter der Pastatheorie passen – oder zumindest nahe daran liegen. Hier sind einige andere leckere Gerichte, die Sie in einem Restaurant bestellen können, aber Anti-Patterns, die Sie als Code-Architektur vermeiden sollten:
- Makkaronicode: Quelldateien, die aus mehreren Programmiersprachen bestehen;
- Strombolicode: Spritzt von einem Ende, wenn man auf das andere beißt;
- Campanellecode: Erstellt mit einem Framework, von dem fast niemand je gehört hat; und
- Baklavacode: Ähnlich wie Lasagnecode, eine Codebasis mit zu vielen architektonischen oder abstrahierten Schichten.
Egal, welche Metapher Sie auf dem Teller haben, denken Sie daran, dass bewährte Programmierverfahren nicht ewig halten. Die Programmiermuster von heute können schnell zu den Anti-Patterns von morgen werden. So sehr Sie schwer zu wartenden Code vermeiden sollten, können selbst gut gestaltete Codebasen in ein paar Jahren veraltet und verschimmelt sein. Was wirklich zählt, ist, dass Sie den Code aktuell, leicht lesbar und für die Wartbarkeit dokumentiert halten.
