In der Softwaretechnik sind ein Antimuster (oder Antimuster) ein Muster, das allgemein verwendet werden kann, aber unwirksam und/oder in der Praxis gegenwirkend ist.

Der Begriff wurde 1995 von Andrew Koenig, ins Leben gerufen

begeistert von der Bande der Buchdesignmuster von Four, die das Konzept von Designmustern im Softwarefeld entwickelt haben. Der Begriff wurde drei Jahre später durch das Buch AntiPatterns weit verbreitet, der den Gebrauch des Begriffes außer dem Feld des Softwaredesigns und in die allgemeine soziale Wechselwirkung erweitert hat. Gemäß den Autoren der Letzteren muss es mindestens zwei Schlüsselelement-Gegenwart geben, um ein wirkliches Antimuster von einer einfachen schlechten Gewohnheit, schlechter Praxis oder schlechter Idee formell zu unterscheiden:

• Ein wiederholtes Muster der Handlung, des Prozesses oder der Struktur, die am Anfang scheint, vorteilhaft zu sein, aber schließlich schlechtere Folgen erzeugt als vorteilhafte Ergebnisse, und
• Eine Alternativlösung besteht, der klar dokumentiert, in der wirklichen Praxis und repeatable bewiesen wird.

Viele Antimuster-Ideen belaufen sich auf ein wenig mehr als Fehler, Wortschwalle, unlösbare Probleme oder schlechte wenn mögliche zu vermeidende Methoden. Manchmal genannt Fallen oder dunkle Muster, dieser informelle Gebrauch des Begriffes ist gekommen, um sich auf Klassen allgemein wiedererfundener schlechter Lösungen von Problemen zu beziehen. So würden viele Kandidat-Antimuster unter der Debatte als Antimuster nicht formell betrachtet.

man wiederholte Fehler formell beschreibt, kann man die Kräfte anerkennen, die zu ihrer Wiederholung führen und erfahren, wie andere refactored selbst aus diesen gebrochenen Mustern haben.

Bekannte Antimuster

Organisatorische Antimuster

• Analyse-Lähmung: Das Widmen unverhältnismäßiger Anstrengung zur Analyse-Phase eines Projektes
• Kassenkuh: Ein gewinnbringendes Vermächtnis-Produkt, das häufig zu Selbstgefälligkeit über neue Produkte führt
• Design durch das Komitee: Das Ergebnis, viele Mitwirkende zu einem Design, aber keine Vereinheitlichen-Vision zu haben
• Eskalation des Engagements: Das Scheitern, eine Entscheidung zu widerrufen, wenn es falschen beweist
• Management durch perkele: Autoritärer Stil des Managements ohne Toleranz der Meinungsverschiedenheit
• Management durch Ziele: Management durch Zahlen, konzentrieren Sie sich exklusiv auf quantitative Verwaltungskriterien, wenn diese unwesentlich sind oder zu viel kosten, um zu erwerben.
• Moralische Gefahr: Das Isolieren eines Entscheidungsträgers von den Folgen seiner oder ihrer Entscheidung
• Pilzmanagement: Das Halten von Angestellten uninformiert und falsch berichtet; Angestellte werden als beschrieben, in der Dunkelheit und dem gefütterten Mist behalten werden, der zum Fischteich verlassen ist, und schließlich konserviert ist.
• Ofenrohr oder Silo: Eine Struktur, die größtenteils unten Datenfluss unterstützt, aber böse organisatorische Kommunikation hemmt
• Verkäufer-Schloss - in: Das Bilden eines Systems, das übermäßig von einem äußerlich gelieferten Bestandteil abhängig

Projektverwaltungsantimuster

• Lawine: Ein unpassender mashup des Wasserfalls vorbildliche und Flinke Entwicklungstechniken
• Trauermarsch: Jeder weiß, dass das Projekt dabei ist, eine Katastrophe - außer dem CEO zu sein - so wird die Wahrheit verborgen, um unmittelbare Annullierung des Projektes - zu verhindern (obwohl der CEO häufig weiß und es irgendwie tut, um Gewinn zu maximieren). Jedoch bleibt die Wahrheit verborgen, und das Projekt wird künstlich bewahrt, bis die Tagesnull schließlich ("Urknall") kommt. Alternative Definition: Angestellte werden unter Druck gesetzt, um späte Nächte und Wochenenden auf einem Projekt mit einem unvernünftigen Termin zu arbeiten.
• Groupthink: Während groupthink vermeiden Mitglieder der Gruppe, Gesichtspunkte außerhalb der Bequemlichkeitszone der Einigkeit zu fördern, denkend
• Übertechnik: Ausgaben von Mitteln, die ein Projekt robuster machen, das und kompliziert ist als, sind erforderlich
• Rauch und Spiegel: Das Demonstrieren von undurchgeführten Funktionen, als ob sie bereits durchgeführt wurden
• Software bloat: Das Erlauben aufeinander folgende Versionen eines Systems, jemals mehr Mittel zu fordern

Analyse-Antimuster

• Zuschauer-Teilnahmslosigkeit: Wenn eine Voraussetzungs- oder Designentscheidung falsch ist, aber die Leute, die das bemerken, tun nichts, weil sie eine größere Anzahl der Leute betrifft

Softwaredesignantimuster

• Abstraktionsinversion: Nicht das Herausstellen der durchgeführten von Benutzern erforderlichen Funktionalität, so dass sie es mit höheren Niveau-Funktionen wiederdurchführen
• Zweideutiger Gesichtspunkt: Das Präsentieren eines Modells (gewöhnlich Objektorientierte Analyse und Design (OOAD)), ohne seinen Gesichtspunkt anzugeben
• Großer Ball des Schlamms: Ein System ohne erkennbare Struktur
• Database-as-IPC: Das Verwenden einer Datenbank als die Nachrichtenwarteschlange für die alltägliche Zwischenprozess-Kommunikation, wo ein viel leichterer Mechanismus passender sein würde
• Goldüberzug: Ständig, um an einer Aufgabe oder Projekt gut vorbei am Punkt zu arbeiten, an dem Extraanstrengung Wert hinzufügt
• Wirkung der inneren Plattform: Ein so anpassbares System, dass es eine schlechte Replik der Softwareentwicklungsplattform wird
• Eingangsimprovisationslösung: Das Scheitern, das Berühren vielleicht des Invaliden anzugeben und durchzuführen, hat eingegeben
• Schnittstelle bloat: Das Bilden einer so starken Schnittstelle, dass es äußerst schwierig ist, durchzuführen
• Magische Drucktaste: Das Codieren der Durchführungslogik direkt innerhalb des Schnittstelle-Codes, ohne Abstraktion zu verwenden
• Rasse-Gefahr: Das Scheitern, die Folge von verschiedenen Ordnungen von Ereignissen zu sehen
• Ofenrohr-System: Ein kaum haltbarer Zusammenbau von schlecht-zusammenhängenden Bestandteilen

Objektorientierte Designantimuster

• Blutarmes Bereichsmodell: Der Gebrauch des Bereichsmodells ohne jede Geschäftslogik. Die Bereichsmustergegenstände können ihre Genauigkeit jederzeit nicht versichern, weil ihre Gültigkeitserklärungs- und Veränderungslogik irgendwo draußen (am wahrscheinlichsten in vielfachen Plätzen) gelegt wird.
• BaseBean: Das Übernehmen der Funktionalität von einer Dienstprogramm-Klasse, anstatt daran zu delegieren
• Rufen Sie super: Das Verlangen von Unterklassen, eine überrittene Methode einer Superklasse zu nennen
• Kreisellipse-Problem: Das Subschreiben von variablen Typen auf der Grundlage von Wertsubtypen
• Kreisförmige Abhängigkeit: Das Einführen unnötiger direkter oder indirekter gegenseitiger Abhängigkeiten zwischen Gegenständen oder Softwaremodulen
• Unveränderliche Schnittstelle: Das Verwenden von Schnittstellen, um Konstanten zu definieren
• Gott-Gegenstand: Das Konzentrieren zu vieler Funktionen in einem einzelnen Teil des Designs (Klasse)
• Gegenstand-Senkgrube: Das Wiederverwenden wendet ein, wessen sich Staat (vielleicht implizit) Vertrag für den Wiedergebrauch nicht anpasst
• Gegenstand-Orgie: Das Scheitern, Gegenstände richtig kurz zusammenzufassen, die uneingeschränkten Zugang zu ihrem internals erlauben
• Klopfgeister: Gegenstände, deren alleiniger Zweck ist, Information zu einem anderen Gegenstand zu passieren
• Folgende Kopplung: Eine Klasse, die verlangt, dass seine Methoden eine besondere Ordnung herbeigerufen werden
• Jo-Jo-Problem: Eine Struktur (z.B, des Erbes), der hart ist, wegen der übermäßigen Zersplitterung zu verstehen

Programmierung von Antimustern

• Zufällige Kompliziertheit: Das Einführen unnötiger Kompliziertheit in eine Lösung
• Handlung in einer Entfernung: Unerwartete Wechselwirkung zwischen weit getrennten Teilen eines Systems
• Gutgläubigkeit: Haben Sie der Überprüfung von (a) an der Genauigkeit einer übler Programmfehler-Lage oder (b) das Ergebnis eines Unterprogramms Mangel
• Bootsanker: Das Behalten eines Teils eines Systems, das nicht mehr jeden Nutzen hat
• Das beschäftigte Warten: Das Verbrauchen der Zentraleinheit, während man auf etwas wartet, um, gewöhnlich durch die wiederholte Überprüfung statt der Nachrichtenübermittlung zu geschehen
• Das Verstecken des Misserfolgs: Das Vergessen, eine Fehlerfahne neu zu fassen, als ein Fehler korrigiert worden ist
• Ladungskultprogrammierung: Das Verwenden von Mustern und Methoden, ohne warum zu verstehen
• Das Codieren durch die Ausnahme: Das Hinzufügen neuen Codes, um jeden speziellen Fall zu behandeln, wie es anerkannt wird
• Sich verbergender Fehler: Das Verfangen einer Fehlermeldung, bevor es dem Benutzer und entweder Vertretung von nichts oder Vertretung einer sinnlosen Nachricht gezeigt werden kann
• Harter Code: Das Einbetten von Annahmen über die Umgebung eines Systems in seiner Durchführung
• Lava-Fluss: Das Behalten unerwünscht (überflüssig oder niedrige Qualität) codiert, weil das Entfernen davon zu teuer ist oder unvorhersehbare Folgen hat
• Folge des Schleife-Schalters: Verschlüsselung einer Reihe folgender Schritte mit einem Schalter innerhalb einer Schleife-Behauptung
• Zauberzahlen: Einschließlich unerklärter Zahlen in Algorithmen
• Magische Schnuren: Einschließlich wörtlicher Schnuren im Code, für Vergleiche, als Ereignis-Typen usw.
• Das Wiederholen von sich: Das Schreiben codiert, der wiederholende Muster und Teilketten wieder enthält; vermeiden Sie mit einmal und nur einmal (Abstraktionsgrundsatz)
• Weicher Code: Speicherung der Geschäftslogik in Konfigurationsdateien aber nicht Quelle codiert
• Spaghetti-Code: Programme, deren Struktur, besonders wegen des Missbrauchs von Codestrukturen kaum verständlich

• Schrotflinte-Chirurgie: Entwickler fügt Eigenschaften zu einer Anwendung codebase hinzu, die eine Vielfältigkeit von implementors oder Durchführungen in einer einzelnen Änderung abmessen.

Methodologische Antimuster

• Kopie und Teig-Programmierung: Das Kopieren (und das Ändern) vorhandener Code, anstatt allgemeine Lösungen zu schaffen
• Goldener Hammer: Das Annehmen, dass eine Lieblingslösung allgemein anwendbar ist (Sieh: Silberkugel)
• Unglaubwürdigkeitsfaktor: Das Annehmen, dass es unwahrscheinlich ist, dass ein bekannter Fehler vorkommen wird
• Syndrom von Not Invented Here (NIH): Die Tendenz zur Wiedererfindung des Rades (Scheiternd, eine vorhandene, entsprechende Lösung anzunehmen)

• Frühoptimierung: Bald für die wahrgenommene Leistungsfähigkeit codierend, gutes Design, Haltbarkeit, und manchmal sogar wirkliche Leistungsfähigkeit opfernd
• Die Programmierung durch die Versetzung (oder "die Programmierung zufällig"): Das Versuchen, sich einer Lösung durch das aufeinander folgende Ändern des Codes zu nähern, um zu sehen, ob es arbeitet
• Die Wiedererfindung des Quadratrades: Das Scheitern, eine vorhandene Lösung und stattdessen das Übernehmen einer kundenspezifischen Lösung anzunehmen, die viel schlechter leistet als der vorhandene
• Silberkugel: Das Annehmen, dass eine technische Lieblingslösung einen größeren Prozess oder Problem lösen kann
• Prüfer Gesteuerte Entwicklung: Software springt vor, in dem neue Voraussetzungen im Programmfehler angegeben werden, berichtet

Konfigurationsverwaltungsantimuster

• Abhängigkeitshölle: Probleme mit Versionen von erforderlichen Produkten
• DLL Hölle: Unzulängliches Management von Bibliotheken der dynamischen Verbindung (DLLs), spezifisch auf Windows von Microsoft
• Erweiterungskonflikt: Probleme mit verschiedenen Erweiterungen auf pre-Mac OS X Versionen des Mac OS, der versucht, dieselben Teile des Betriebssystems zu flicken
• GLAS-Hölle: Überanwendung der vielfachen GLAS-Dateien, gewöhnlich versioning und Positionsprobleme wegen des Missverständnisses des javanischen Klassenladen-Modells verursachend

Siehe auch

• Codegeruch - Symptom von der ungesunden Programmierung
• Liste von Softwareentwicklungsphilosophien - Annäherungen, Stile, Sprichwörter und Philosophien für die Softwareentwicklung
• Software Grundsatz von Peter
• Fähigkeitsminderjährigkeitsmodell
• ISO 29110: Softwarelebenszyklus-Profile und Richtlinien für Sehr Kleine Entitäten (VSEs)

Weiterführende Literatur

Links

• Antimuster an WikiWikiWeb
• Antimuster-Katalog
• AntiPatterns.com bestellt die Website für AntiPatterns vor
• Muster des toxischen Verhaltens