Fünf Anti-Patterns, die man strukturell abstellt

Anti-Patterns werden meist als Fehler dargestellt. Besser versteht man sie als lokal vernünftige Entscheidungen mit schlechten Gesamtfolgen — weshalb der Appell, sie zu vermeiden, nicht wirkt und die Abhilfe strukturell statt erzieherisch ist.

Jedes der fünf bleibt bestehen, weil es im Moment die schnellste Option war. Beseitigt wird es, indem man ändert, was die schnellste Option ist.

1. Verworrener Ablauf

Das Muster: Logik, der man nicht folgen kann, ohne die ganze Datei im Kopf zu halten. Fünffach verschachtelte Bedingungen, eine Funktion, die sechs Dinge tut, Zustand, der an Stellen verändert wird, die der Name nicht nahelegt.

Warum es bleibt. Es entsteht selten auf einmal. Jede Ergänzung war eine kleine, sinnvolle Änderung an Code, der bereits leicht verworren war. Niemand hat das Durcheinander eingeführt; es ist angewachsen.

Die geschäftliche Folge. Änderungen werden unvorhersehbar — dieselbe Anfrage dauert in einem Bereich eine Stunde und im anderen drei Tage, ohne dass man es vorher sagen könnte. Diese Unvorhersehbarkeit zerstört das Vertrauen in Schätzungen.

Was es beseitigt: eine Grössengrenze, die das Gespräch erzwingt. Keine Stilregel, sondern eine Review-Frage — «kann eine neue Person dem folgen?». Und vor allem: Refactoring als Teil der Funktionsarbeit budgetiert statt als Projekt, das nie bewilligt wird.

2. Gott-Objekte

Das Muster: eine Klasse oder ein Modul, das von allem weiss. Jede Funktion berührt es, also gefährdet jede Änderung alles.

Warum es bleibt. Etwas dort zu ergänzen, wo der Kontext schon liegt, ist immer schneller, als eine neue Grenze zu ziehen und anzubinden. Das stimmt in jedem Einzelfall und ist in der Summe falsch.

Die geschäftliche Folge. Es wird zum Engpass für parallele Arbeit. Zwei Personen können es nicht gefahrlos gleichzeitig ändern, also serialisiert sich das Team um eine Datei — was wie ein Personalproblem aussieht und ein Architekturproblem ist.

Was es beseitigt: nach fachlichen Fähigkeiten schneiden statt nach technischen Schichten — dasselbe Prinzip wie in Legacy-Modernisierung ohne Betriebsunterbruch. Eine Fähigkeit lässt sich einzeln ändern und zurücknehmen; ein Gott-Objekt nicht.

3. Kopierte Logik

Das Muster: dieselbe Regel an vier Stellen umgesetzt, weil Kopieren schneller war, als die richtige Abstraktion zu finden.

Warum es bleibt. Es ist tatsächlich schneller, und die Kosten trägt, wer die Regel später ändert — meist eine andere Person, oft in einem anderen Jahr.

Die geschäftliche Folge. Dieses Muster erzeugt falsche Antworten, nicht nur langsame. Die Regel ändert sich, drei Kopien werden angepasst, die vierte übersehen — und zwei Teile des Systems widersprechen sich. In einem regulierten Umfeld ist das kein Fehler, sondern ein Prüfbefund.

Was es beseitigt: zu wissen, wo Geschäftsregeln leben. Kann eine Entwicklerin «wo ist die Rabattregel umgesetzt?» nicht in unter einer Minute beantworten, entstehen weiter Kopien — unabhängig von Disziplin.

4. Schwache Praxis bei der Versionskontrolle

Das Muster ist heute selten gar keine Versionskontrolle. Es ist schlecht genutzte: Commits, die sechs unzusammenhängende Änderungen bündeln, monatelang lebende Branches, Meldungen wie «Korrekturen», eine Historie, die niemand lesen kann.

Warum es bleibt. Disziplin hat hier keinen unmittelbaren Ertrag. Sie kostet jetzt etwas und spart später viel — die denkbar schlechteste Anreizform.

Die geschäftliche Folge. Sie verlieren die Fähigkeit, «wann ist das kaputtgegangen und was hat sich geändert?» zu beantworten — die erste Frage bei jeder Störung. Und für alles unter revDSG/nDSG, DSGVO, IEC 62304 oder FINMA-Erwartungen ist die Änderungshistorie Teil der Nachweise, die Sie vorlegen müssen.

Was es beseitigt: kurzlebige Branches, kleine Commits und eine Konvention für Meldungen, die das Review übersteht. Die regulatorische Rahmung hilft hier — sie macht aus einer Vorliebe eine Anforderung.

5. Verfrühte Optimierung

Das Muster: Komplexität für eine Leistung, deren Problem nie gemessen wurde. Caches, die Aktualitätsfehler erzeugen, denormalisierte Daten, die auseinanderlaufen, Nebenläufigkeit, wo sequenziell gereicht hätte.

Warum es bleibt. Es fühlt sich nach Professionalität an. Skalierung vorauszudenken ist, was eine erfahrene Person tun soll.

Die geschäftliche Folge. Sie zahlen die Komplexität sofort und dauerhaft, für einen Nutzen, der vielleicht nie eintritt. Schlimmer: Die zusätzliche Komplexität erschwert oft das Auffinden des echten Engpasses, wenn er auftritt — und er tritt meist dort auf, wo ihn niemand vorhergesagt hat.

Was es beseitigt: Messung vor Optimierung, ausnahmslos. Und die umgekehrte Disziplin, die praktisch mehr zählt: zu wissen, welche Leistungsentscheidungen tatsächlich architektonisch sind und sich nicht aufschieben lassen — die Form des Datenmodells, synchrone gegen asynchrone Grenzen, alles, dessen Änderung einen Neubau verlangte.

Was daraus folgt

Eine Liste von Anti-Patterns zu lesen ändert für sich nichts. Drei Eingriffe schon:

Den gesunden Weg zum schnellen Weg machen. Braucht ein neues Modul zwanzig Minuten Gerüstarbeit und die Ergänzung am Gott-Objekt zwei, gewinnt das Gott-Objekt jedes Mal — unabhängig davon, was alle für richtig halten.

Refactoring innerhalb der Funktionsarbeit budgetieren. Ein Aufräumprojekt gegen Funktionen verliert dauerhaft. Eine Funktion, die ihren Bereich besser hinterlässt, nicht.

Den Verlauf beobachten, nicht die Momentaufnahme. Das relevante Signal ist, ob der Anteil der Wartungszeit steigt. Er zeigt sich in Finanzdaten, bevor er sich im Code zeigt — siehe Engineering-ROI maximieren: Leitfaden für Finanzchefs.

Weiterführend

• Legacy-Modernisierung ohne Betriebsunterbruch
• Agile Praktiken, die in Schweizer Teams standhalten
• Softwareentwicklung

Wenn Schätzungen in einem Teil Ihres Systems unvorhersehbar sind und Sie wissen möchten warum, vereinbaren Sie ein Gespräch. Unverbindlich.