Softwareentwicklung: Antipatterns – die böse Schwester der Design Patterns

Inhaltsverzeichnis

Ein Antipattern ist eine bewährte Methode, um sich selbst in den Fuß zu schießen. Der Begriff Antipattern wurde von Andrew Koenig geprägt, und es ist ziemlich unterhaltsam, darüber zu lesen. Das Buch "Design Patterns: Elements of Reusable Object-Oriented Software" (Design Patterns), das 1994 veröffentlicht wurde, definiert Antipatterns als einen "commonly-used process, structure or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones."

1998 wurde der Begriff dann dank des Buchs "Antipatterns: Refactoring Software, Architectures, and Projects in Crisis" (Antipatterns) populär. Es definierte Antipatterns als "specific repeated practices in software architecture, software design, and software project management that initially appear to be beneficial, but ultimately result in bad consequences that outweigh hoped-for advantages."

Kurz gesagt: Ein Antipattern ist eine häufig angewandte Praxis, die mehr schlechte als gute Folgen hat.

Im folgenden Absatz werden einige Theorien über Antipatterns in aller Kürze vorgestellt. Das Konzept basiert auf dem Buch "Antipatterns: Refactoring Software, Architectures, and Projects in Crisis", in dem ausführlichere Informationen zu finden sind.

Projects in Crisis

Ein Antipattern ist ähnlich wie ein Design Pattern eine literarische Form und vereinfacht die Kommunikation und Beschreibung eines häufig auftretenden Problems. Oft ist es ein Muster, das im falschen Kontext angewendet wird. Folgendes sind die sieben Hauptursachen für Antipatterns:

• Hast
• Desinteresse
• Engstirnigkeit
• Faulheit
• Geiz
• Ignoranz
• Stolz

Als Gegenmaßnahme dafür müssen beim Softwaredesign die folgenden elementaren Kräfte bei der Entscheidungsfindung berücksichtigt werden:

• Funktionalitätsmanagement
• Leistungsmanagement (nicht-funktionaler Anforderungen)
• Komplexitätsmanagement
• Management der Änderungen
• Management von IT-Ressourcen
• Management des Technologietransfers

Jedes Antipattern besitzt die folgenden drei Komponenten:

• Name: eindeutiger Name mit negativer Konnotation
• Problem: weit verbreitete Praxis mit schlechten Folgen
• Refactoring: Vermeidung des Antipatterns oder Minimierung seiner Auswirkungen

Das Buch Antipatterns stellt drei typische Bereiche für Antipatterns vor:

• Software-Entwicklung: Eine angemessene Softwarestruktur ist für die Systemerweiterung und -wartung unerlässlich, aber die Software-Entwicklung ist oft eine chaotische Tätigkeit. Software-Refactoring ist der Schlüssel zur Verbesserung der Softwarestruktur.
• Software-Architektur: Die Architektur konzentriert sich auf die Struktur der System- und Unternehmensebene. Gute Architektur ist Schlüsselfaktor für Erfolg der Systementwicklung und kann durch architekturgesteuerte Software-Entwicklung erreicht werden.
• Software-Projektmanagement: Moderne Software-Entwicklung hängt hauptsächlich von menschlicher Kommunikation ab. Schlechtes Projektmanagement kann sich zerstörerisch auf Softwareprozesse auswirken. Lösungen für die Antipatterns bestehen darin, unproduktive Grenzen zu beseitigen und Entwickler zu befähigen, eigene Entscheidungen zu treffen.

Nun kommt der unterhaltsame Teil dieses Artikels: Ich werde einige Antipattern vorstellen, die der Klassifizierung des Antipatterns-Buchs folgen. Darüber hinaus enthält die Aufzählung einige Antipatterns aus anderen Quellen und offensichtliche Gründe für die vorgestellten Anti-Muster.

Antipattern in der Software-Entwicklung

• Cut-and-Paste-Programmierung (auch bekannt als Copy-and-Paste): Wiederverwendeter Code durch das Kopieren von Quelltexten führt zu erheblichen Wartungsproblemen. Das Unternehmen besitzt keine Kultur der Wiederverwendung von Code. Auch ein Mangel an Abstraktion oder fehlende Kommunikation kann die Ursache sein.
• Lava Flow (auch bekannt als toter Code): Toter Code und vergessene Designinformationen werden in einem sich ständig ändernden Design eingefroren. Der Schwerpunkt kann auf der Entwicklung neuer Funktionen liegen. Es bleibt keine Zeit für das Refactoring des Codes.
• Zwiebel: Neuer Code wird um den alten gewickelt. Es ist oft einfacher, eine zusätzliche Abstraktionsschicht hinzuzufügen, als die Software zu re-faktorisieren und ihre interne Struktur zu verbessern.
• Schweizer Taschenmesser (auch bekannt als Küchenspüle): Das Ein-Werkzeug-Wunder ist eine universelle Lösung für alle Bedürfnisse; ein Allheilmittel. Dieses Anti-Muster ist eng mit dem Goldenen-Hammer-Syndrom verbunden.
• Goldener Hammer (auch bekannt als head-in-the-sand): Ein Goldener Hammer ist eine vertraute Technologie oder ein Konzept, das zwanghaft auf viele Softwareprobleme angewendet wird. Ein Mangel an Wissen über alternative Strategien ist ein häufiger Grund. Außerdem haben sich die bisherigen Lösungen bewährt und werden immer wieder verwendet.

Software-Architektur Antipattern

• Die Gott-Klasse (der Blob): Eine "Gott-Klasse" ist ein Objekt, das zu viele andere Objekte im System steuert und über jede Logik hinausgewachsen ist, um zu einer Klasse zu werden, die alles tut. Oft ist es einfacher, einer Klasse eine Mitgliedsfunktion hinzuzufügen, als eine Design-Dekomposition vorzunehmen.
• Spaghetti-Code: Spaghetti-Code ist ein abwertender Ausdruck für unstrukturierten und schwer zu pflegenden Quellcode. Die offensichtlichen Gründe können die übermäßige Verwendung von GOTO-Anweisungen, Ausnahmebehandlung oder tief verschachtelte if-else-Strukturen sein. Dies ist gerne gepaart mit mangelnden Abstraktion und architektonische Dekomposition.
• Big Ball of Mud: Einem Softwaresystem fehlt eine erkennbare Architektur. Ein typischer Grund ist zeit- und funktionsgetriebenes Design.

Antipattern im Projektmanagement

• Brooks' Gesetz: "Adding manpower to a late software project makes it later". Neue Mitarbeiter:innen verlangsamen den Entwicklungsprozess, weil sie erst durch die erfahrenen Mitarbeiterinnen eingearbeitet werden müssen.
• Todesmarsch: ein Projekt, von dem die Beteiligten glauben, dass es zum Scheitern verurteilt ist, oder das unhaltbare Mehrarbeit erfordert. Die Unternehmenskultur basiert auf Kontrolle, aber nicht auf Vertrauen. Abweichende Meinungen werden nicht akzeptiert.
• Pilzmanagement: "Keep them in the dark and feed them full of shit.” In einigen Architektur- und Managementkreisen gibt es die ausdrückliche Politik, Systementwickler von den Endnutzern des Systems zu isolieren. Die Unternehmenskultur basiert wie beim Antipattern Todesmarsch auf Kontrolle, aber nicht auf Vertrauen.

Wie geht's weiter?

In meinem nächsten Beitrag im Blog "Modernes C++" werde ich über die klassischen Entwurfsmuster schreiben. Den Anfang werden die Erzeugungsmuster machen. (sih)