Ein Anti-Pattern (aus dem Englischen, übersetzt etwa Antimuster) ist ein Oberbegriff für Verhaltensmuster, die speziell in der Softwareentwicklung anzutreffen und zumeist auch allgemein auf Organisationen übertragbar sind. Als Anti-Pattern werden Lösungsansätze bezeichnet, die ungünstig oder schädlich für den Erfolg eines Projektes oder einer Organisation sind. Sie bilden das Gegenstück zu Pattern (englisch Muster), welche gute und bewährte Problemlösungsansätze darstellen.
Das Konzept von Mustern wurde vor allem durch die Entwurfsmuster aus dem Buch von 1994: „Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software“ (Originaltitel Design Patterns. Elements of Reusable Object-Oriented Software) bekannt. Diese umfassen jeweils eine Beschreibung einer prototypischen Problemsituation samt Lösungsvorschlag. Nachdem Muster in der Softwareentwicklung zunehmend erfolgreich eingesetzt wurden, wurden auch Negativbeispiele thematisiert, um wiederkehrende Fehler zu identifizieren, zu dokumentieren und Maßnahmen zur Behebung aufzuzeigen. So wie sich Muster nicht nur auf den Entwurf von Software beschränken und es auch beispielsweise Kataloge für Analysemuster, Architekturmuster oder Organisationsmuster gibt, beschränken sich auch Anti-Pattern nicht nur auf den Quelltext und die Softwarearchitektur, sondern haben häufig Projektmanagement und Unternehmensprozesse zum Gegenstand.
In der Regel entstehen Anti-Pattern durch mangelhafte Erfahrung oder fehlende Qualifikation. Zu beobachten ist auch der bewusste Einsatz von Anti-Pattern, um zum eigenen Vorteil einen bestimmten, vom eigentlichen Projektziel abweichenden Zweck zu erreichen.
Kategorisierung Mittlerweile werden die Vorkommen von Anti-Pattern immer feiner unterschieden. Sie fächern sich auf von der reinen Software-Programmierung (hier spricht man auch von Code-Smells, die bei Existenz und Identifikation durch Refactorings entfernt werden können), gehen weiter zu Architektur und Design, wirken im Projektmanagement und in Unternehmensprozessen und -organisation sowie im Management. Darüber hinaus können in der Praxis häufiger sogenannte Meta-Patterns identifiziert werden. Diese vereinen einzelne Muster zu neuen, abstrakteren Mustern oder führen weitere Dimensionen oder abstraktere Kategorisierungen ein.
Projektmanagement-Anti-Pattern
Blendwerk Das Blendwerk (englisch ) bezeichnet nicht fertige Funktionen, welche als fertig vorgetäuscht werden.
Aufgeblähte Software
Aufgeblähte Software bezeichnet Software, die mit unnötigen Zusatzfunktionen oder Ressourcenverschwendung aufgebläht wird und damit den eigentlichen Anwendungszweck kaum oder gar nicht verbessert.
Feature creep „Feature creep“ (dt. etwa „Einschleichen von Funktionalität“) bezeichnet es, wenn der Umfang der zu entwickelnden Funktionalität in einem Projektplan festgehalten wird, diese aber dauernd erweitert wird.
Der Kunde versucht nach der Erstellung des Projektplanes weitere Funktionalität in der Version mit unterzubringen. Dies führt zu Problemen, wenn die in Arbeit befindliche Version nicht das notwendige Design aufweist, Termine nicht eingehalten werden können oder die realen Kosten über die planmäßigen Kosten wachsen.
Bei konventionellen Prozessen ist dies problematisch aufgrund ihrer fixierten Abläufe und Aktivitäten. Bei agilen Prozessen wie Extreme Programming (XP) müssen bei allen Beteiligten die Konsequenzen bekannt sein. Ein systematisches Anforderungsmanagement und Änderungsmanagement sind in beiden Fällen obligatorisch. Gewisse Änderungen am Projektplan während der Entwicklung sind in größeren Projekten schwer vermeidbar, denn die Spezifikationen bis ins letzte Detail auszuarbeiten ist meist noch aufwendiger, als etwas Reserve einzuplanen. Auch können Anforderungen erst während der Entwicklung entdeckt werden.
Extreme, böswillige und grob fahrlässige Anwendung dieses Musters kann dadurch motiviert sein, dass der Auftraggeber, der immer neue Funktionalität fordert, das Produkt boykottieren möchte und dessen Abschluss zu verhindern sucht, oder er hat bei der Planung bewusst eigentlich benötigte Funktionalität unterschlagen, um eine günstigere Offerte zu erhalten.
Durch ein Wortspiel, dessen Inhalt die Wandlung von Creeping Feature zu Feeping Creature umfasst, wird der Umstand ausgedrückt, dass eine Verselbstständigung von Anforderungen und Implementierungen unnötiger oder nicht in das Gesamtkonzept passender Leistungsmerkmale stattgefunden hat.
Scope creep Der „Scope creep“ (dt. etwa „Einschleichen weiterer Anwendungsbereiche“) ist ähnlich dem Feature creep, jedoch weniger auf Funktionalität bezogen, sondern auf den sich verändernden Anwendungsbereich.
In der Praxis zeichnet sich der Auftraggeber häufig dadurch aus, dass er den Umfang der Software nachträglich erweitert, ohne dies explizit zuzugeben. Beispiel: Nicht diskutierte Anwendungsbereiche werden plötzlich als sehr wichtig dargestellt bzw. das Fehlen eines Bereichs wird als Fehler dargestellt, der dringend behoben werden muss.
Als eine Gegenmaßnahme dient ein systematisches und konsequentes Inhalts- und Umfangsmanagement.
Brooks’sches Gesetz Das Brooks’sche Gesetz besagt, dass ein hinter seinem Zeitplan herhinkendes Projekt länger benötigt, wenn neue Mitarbeiter eingestellt werden, weil die neuen Mitarbeiter Zeit benötigen, um sich einzuarbeiten, und sie dabei die etablierten Kollegen abbremsen.
Death Sprint Bei einem Death Sprint (Überhitzter Projektplan) wird Software iterativ bereitgestellt. Die Bereitstellung erfolgt hierbei in einer viel zu kurzen Zeitspanne. Nach außen sieht das Projekt zunächst sehr erfolgreich aus, da immer wieder neue Versionen mit neuen Eigenschaften abgeschlossen werden. Allerdings leidet die Qualität des Produktes sowohl nach außen sichtbar wie auch technisch, was allerdings nur der Entwickler erkennt. Die Qualität nimmt mit jeder „erfolgreichen“ neuen Iteration ab. Der Death Sprint ist das Gegenstück zum Death March.
Death March Ein Death March (Todesmarsch; gelegentlich auch Himmelfahrtskommando) ist das Gegenstück zu einem Death Sprint (Überhitzten Projektplan; s. o.). Ein Todesmarschprojekt zieht sich ewig hin.
In einem optimalen Fall werden zwar Vorabversionen bereitgestellt, welche aber von schlechter Qualität sind. Der Misserfolg ist objektiv sichtbar. Es können keine Meilensteine gehalten werden bzw. es existieren gar keine. Schlimmstenfalls kann eine Konsequenz daraus sein, dass das Projekt kein Projekt mehr ist, sondern nur eine zeitlich nicht abgeschlossene Aneinanderreihung von Aktivitäten. Es fehlen konkrete Zusagen für Termine und Lieferung von Eigenschaften.
Ein Todesmarschprojekt kann auch bewusst in Kauf genommen werden, um von Defiziten in der Organisation abzulenken und Entwicklungen zu verschleppen, d. h. so lange an etwas zu entwickeln, bis eine nicht genau spezifizierte Eigenschaft in irgendeiner Form subjektiv funktioniert. Wenn sowohl Anforderungsmanagement als auch Änderungsmanagement nicht vorhanden sind und das Projekt kein Projekt mehr ist, so schlenkert das Entwicklungsprodukt orientierungslos umher, und seine Qualität nimmt stetig ab.
Ein Todesmarschprojekt kann auch mit einem Überhitzten Projektplan (s. o.) kombiniert werden, um nach außen von Planungslosigkeit und Defiziten bei Organisation und Technik abzulenken. Es wird dann Funktionalität als neu dargestellt, die bereits lange existiert, oder es existiert keine Kontrollinstanz, die Notwendigkeit, Relevanz, Form, Korrektheit und Wichtigkeit von bereitgestellter Funktionalität bewertet.
Beispiel Neuanforderungen von gestern sind (nicht: beinhalten!) die Bugs von morgen.
Ein Todesmarschprojekt kommt häufig vor, wenn es keine Stakeholder gibt, die Interesse an dem Produkt haben, oder wenn der in das Produkt einfließende Aufwand oder sogar das ganze Produkt letztendlich keine Bedeutung/Wichtigkeit hat. In diesem Fall beschäftigt sich die Unternehmung oder die Entwicklungsabteilung nicht selten (mit sich) selbst.
Architektur- bzw. Entwurfs-Anti-Pattern
Big Ball of Mud
Software, die keine erkennbare Softwarearchitektur besitzt, wird als Big Ball of Mud (Großer Matschklumpen) bezeichnet.
Gasfabrik Als Gasfabrik (englisch ) werden abwertend unnötig komplexe Systementwürfe für relativ simple Probleme bezeichnet.Guido Stepken: auf der Webseite little-idiot.de
Gottobjekt
Die Begriffe Gottobjekt (englisch ), Gottklasse () und Blob bezeichnen ein Objekt (im Sinne der objektorientierten Programmierung), das zu viel weiß bzw. macht. Die Aufteilung nach Verantwortlichkeiten, Kapselung und die Einhaltung von Entwurfsmustern helfen, diesem Muster zu begegnen.
Innere-Plattform-Effekt Der Innere-Plattform-Effekt (englisch ) tritt auf, wenn ein System derartig weitreichende Konfigurationsmöglichkeiten besitzt, dass es letztlich zu einer schwachen Kopie der Plattform wird, mittels derer es gebaut wurde. Ein Beispiel sind Datenmodelle, die auf konkrete (anwendungsbezogene) Datenbanktabellen verzichten und stattdessen mittels allgemeiner Tabellen eine eigene Verwaltungsschicht für die Datenstruktur implementieren mit dem eigentlichen Ziel, die Flexibilität zu erhöhen. Derartige Systeme sind allerdings typischerweise schwer zu beherrschen und leiden häufig unter zusätzlichen Performanceproblemen.
Spaghetticode
Spaghetticode ist eine sehr kompakte Systemstruktur, die von Sprungbefehlen geprägt ist, deren Kontrollfluss einem Topf Spaghetti ähnelt. Der Code ähnelt einem monolithischen Block und weist eine besonders schlechte Wartbarkeit und Wiederverwendbarkeit auf.
Train Wreck
Beim Train Wreck (deutsch in etwa: Zugunglück) werden mehrere Methodenaufrufe hintereinander verkettet, beispielsweise in vertrag.getKunde().getAdresse().getLand(). Dies führt zusätzliche Abhängigkeiten ein und verletzt somit das Prinzip der losen Kopplung. Dieses Anti-Pattern darf jedoch nicht mit dem sinnvollen Decorator-Pattern verwechselt werden.
Sumo-Hochzeit Als Sumo-Hochzeit (englisch ) bezeichnet man es, wenn ein unnatürlich stark abhängig von der Datenbank ist.
In der Datenbank ist hierbei sehr viel Logik in Form der datenbankeigenen Programmiersprache positioniert. Beispielsweise in Oracle mit der Programmiersprache PL/SQL. Die ganze Architektur ist dadurch sehr unflexibel.
Soll die Anwendung zu einer Internet-Anwendung migriert oder die Datenbank gewechselt werden, so müssen auf beiden Schichten (Client und Datenhaltung) viele Bereiche neu entwickelt werden. Die Systeme sind nicht entkoppelt.
Integrationsdatenbank Eine Integrationsdatenbank (englisch: ) ist eine Datenbank, welche von mehreren Anwendungen direkt verwendet wird, um die Synchronisierung zwischen den Anwendungen sicherzustellen.
Die Alternative zu einer Integrationsdatenbank ist eine . Hierbei handelt es sich um eine Datenbank, auf welche ein einziger Webservice zugreift. Der Webservice stellt die Funktionalität der Datenbank in Form einer REST- oder SOAP-Schnittstelle bereit und kann von verschiedenen Anwendungen verwendet werden.
Programmierungs-Anti-Pattern Doppelt überprüfte Sperrung
Unerfahrene Entwickler implementieren oft eine als fehlerhaft anzusehende doppelt überprüfte Sperrung (englisch ). Dies gilt als Antimuster.
Zwiebel Als Zwiebel (englisch ) bezeichnet man Programmcode, bei dem neue Funktionalität um (oder über) die alte gelegt wird.
Häufig entstehen Zwiebeln, wenn ein Entwickler ein Programm erweitern soll, das er nicht geschrieben hat. Der Entwickler möchte oder kann die bereits existente Lösung nicht komplett verstehen und setzt seine neue Lösung einfach drüber. Dies führt mit einer Vielzahl von Versionen und unterschiedlichen Entwicklern über die Jahre zu einem Zwiebel-System.
Copy and Paste
Programmierung mittels Kopieren und Einfügen (englisch ) bezeichnet es, wenn der Programmierer den Code nicht neu entwickelt, sondern sich bereits existenter Quelltexte bedient, aus denen er Passagen herauskopiert.