Anti-Pattern

Während Entwurfsmuster in der Software-Entwicklung allgemein übliche und bekannte Lösungsansätze sind, um Probleme zu lösen, sind Anti-Patterns Negativ-Beispiele von bereits durchgeführten Lösungen, die Hinweise geben, wie die Aufgabenstellung besser gelöst werden könnte und sollte.

Einordnung

Entwurfsmuster wurden der Allgemeinheit vor allem durch das Buch Design Patterns der Viererbande bekannt. Nachdem bei der Software-Entwicklung immer mehr von positiven Erfahrungen von erfolgreich abgeschlossenen Aufgabenstellungen profitiert wurde, konzentrierte man sich auch darauf die Negativbeispiele, also wiederkehrende Fehler bei der Software-Entwicklung, zu identifizieren und zu dokumentieren. Bereits manifestierte Anti-Pattern können durch geschickte Maßnahmen behoben werden. Das Wissen ihrer Existenz hilft sie zu vermeiden. In der Regel entstehen Anti-Pattern wider besseren Wissens, durch mangelnde Erfahrung oder fehlende Qualifikation. Zu beobachten ist allerdings auch die bewusste Verfolgung in bestimmten Szenarien, um einen bestimmten Zweck zu erreichen. Auswirkungen von Anti-Pattern gehen von marginal bis unternehmenskritisch.

Kategorisierung

Mittlerweile werden Anwendungsbereiche der Anti-Patterns immer feiner unterschieden. So unterscheidet man Anti-Patterns bei der reinen Programmierung (hier spricht man auch von Code smells, die bei Existenz und Identifikation durch Refactorings entfernt werden können), bei Architektur und Design, beim Projekt-Management, bei Unternehmensprozessen, bei der Unternehmensorganisation und Management. Darüber hinaus können in der Praxis immer mehr sogenannte Meta-Patterns identifiziert werden. Diese vereinen einzelne Patterns zu einem neuen, abstrakteren Pattern oder führen eine weitere Dimension oder abstraktere Kategorisierung ein.

Projektmanagement-Anti-Patterns

„Rauch und Spiegel“ (englisch Smoke and mirrors): Nicht fertige Funktionen werden als fertig vorgetäuscht.
„Aufgeblähte Software“ (englisch Software bloat): Jede neue Version benötigt mehr Ressourcen
„Erschleichung von Funktionalität“ (englisch Feature creep): Der Umfang der zu entwickelnden Funktionalität wird in einem Projektplan festgehalten. Der Kunde versucht nach der Erstellung des Projektplanes weitere Funktionalität in die Version mit unterzubringen. Führt zu Problemen wenn die in Arbeit befindliche Version nicht das notwendige Design aufweist, Termine nicht eingehalten werden können oder die Kosten über die planmässigen wachsen. Bei schwergewichten Prozessen sehr gefährlich, bei leichtgewichtigen wie XP müssen bei allen Beteiligten die Konsequenzen klar sein. Ein systematisches Anforderungsmanagement und Änderungsmanagement sind obligatorisch. Extreme, böswillige und grob fahrlässige Anwendung dieses Musters kann dadurch motiviert sein, dass der Auftragsteller, der immer neue Funktionalität fordert, das Produkt boykottieren möchte und dessen Abschluss zu verhindern sucht.
„Erschleichung weiterer Anwendungsbereiche“ (englisch Scope creep): wie Erschleichung von Funktionalität nur nicht auf Funktionalität bezogen sondern auf den Anwendungsbereich. Auch hier zeichnet sich der Auftraggeber dadurch aus, dass er geschickt und versteckt den Umfang der Software nachträglich erweitern möchte ohne dass er dies explizit zugibt. Beispiel: nicht diskutierte Anwendungsbereiche sind plötzlich sehr wichtig bzw. das Fehlen eines Bereiches wird sogar als Fehler dargestellt, der dringendst behoben werden muss.
„Brookssches Gesetz“: Mitarbeiter zu einem verspäteten Softwareprojekt hinzuzufügen verzögert das Projekt nur noch weiter (englisch Adding manpower to a late software project makes it later.

Architektur- bzw. Design-Anti-Patterns

„Außerirdische Spinnen“ (englisch Alien spiders): ein Design, das den Namen nicht verdient. Sehr gesprächige, kommunikative Objekte, die sich alle gegenseitig kennen. Überhaupt keine Nutzung von Entwurfsmustern. Bei n Objekten gibt es n*(n-1)/2 Kommunikationspaare.
„Gasfabrik“ (englisch Gas factory): Eine Gasfabrik ist ein unnötig komplexes Systemdesign für eine recht einfache Aufgabenstellung. Beispielhafte Nutzung: „Ich wollte eine Softwarelösung haben, keine Gasfabrik.“
„Gottobjekt“ (englisch God object): Ein Objekt, das zu viel weiß respektive zu viel macht. Aufteilung nach Verantwortlichkeiten, Kapselung und Einhaltung von Entwurfsmustern helfen diesem Muster zu begegnen. Auch als Gottklasse (God class) und Blob bekannt.
„Spaghetti Code“: Eine sehr kompakte Systemstruktur dessen Kontrollfluss einem Topf Spaghetti ähnelt.
„Sumo Hochzeit“ (englisch Sumo Marriage): Ein Fat Client ist unnatürlich stark abhängig von der Datenbank. In der Datenbank ist sehr viel Logik in Form der datenbankeigenen Programmiersprache positioniert, in Oracle zum Beispiel mit PL/SQL. Die ganze Architektur ist 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.

Programmierungs-Anti-Patterns

Double-Checked Locking in Java

„Doppelt überprüfte Sperrung“ (englisch double-checked locking): eine doppelte Überprüfung bevor eine Sperrung durchgeführt wird. Beispiel: in der Java-Welt, um ein Einzelstück (Singleton) zu erstellen. Wird häufig von einem Sophomore genutzt, der von der Problematik des Lockings weiß, aber die falschen Schlüsse zieht. Obwohl mit Java 5 unter einer neuen Semantik des volatile Schlüsselwortes das double-checked locking thread-safe realisiert werden kann gilt es immer noch als Anti-Pattern, da es zu umständlich und uneffizient ist. Es wird gewöhnlich das Initialization On Demand Holder Idiom genutzt, um ein Singelton zu erzeugen welches vollständig lazy, effizient und thread-safe geladen wird und eine verständliche Implementierung besitzt.
„Zwiebel“ (englisch Onion): neue Funktionalität wird um (oder über) die alte gelegt. Häufig zu beobachten, wenn ein Entwickler ein Programm erweitern soll welches 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.
„Programmierung mittels Copy & Paste“ (englisch Copy And Paste Programming): Der Programmierer entwickelt den Code nicht neu, sondern bedient sich bereits existentem Quelltext aus denen er Passagen herauskopiert. Die Gefahr ist sehr groß, dass er Fehler mit kopiert oder die Kopie für den neuen Bereich nicht optimal einsatzbereit ist. Der Entwickler reflektiert weniger über sein Programm als wenn er jede Zeile selbst entwickeln würde. Fehleranfälliges Vorgehen, wenn der Entwickler nicht weiss was er eigentlich macht. Weit verbreitet.
„Lavafluss“ (englisch Lava flow) ist ein Problem, bei dem Code (der normalerweise unter schlechten Bedingungen geschrieben wurde) in Produktion gebracht wird, obwohl er immer noch im Entwicklungsstatus ist. In der Folge wird der Code meistens von weiteren Komponenten verwendet, so dass er nicht mehr modifiziert werden kann. Lavaflüsse kann man meistens bei einer hohen Mitarbeiterfluktuation vorfinden. Wenn die ursprünglichen Entwickler das Unternehmen verlassen und das Wissen mitnehmen, so ist es meistens für die verbleibenden Mitarbeiter unmöglich die wichtigen Teile des Systems zu identifizieren. Im Termindruck kommt es meistens nicht zu dem lange angekündigten Refactoring und Bereinigen, so dass die Systemkomplexität weiter steigt. Häufig bezeichnet man mit Lavafluss auch den Umstand, dass in der Anwendung immer mehr "toter Quelltext" herumliegt. Dieser wird nicht mehr genutzt. Statt ihn zu löschen werden im Programm immer mehr Verzweigungen eingebaut, die um den besagten Quelltext herumlaufen oder auf ihn aufbauen.

Organisations-, Management- bzw. Prozess-Anti-Patterns

„Goldener Hammer“ (englisch Golden hammer): Ein bevorzugter Lösungsweg wird als universell anwendbar angesehen.
„Das Rad neu erfinden“ (englisch Reinventing the wheel): stetige Neuerstellung von Software ohne bestehende Lösungen oder Rahmenwerke zu nutzen. Keine Wiederverwendung, was zu unstabiler, unreifer, teurer Software führt.
„Das Quadratische Rad neu erfinden“ (englisch Reinventing the square wheel): eine schlechte Lösung bereitstellen wenn eine gute bereits existiert. Beispiel aus der Java Welt: eigene Entwicklung einer Persistenz-Schicht, obwohl es hier reife, verbreitete, durchgetestete de facto Standards gibt wie Hibernate.

"Golden Hammer"
Body ballooning: der Vorgesetzte handelt ausschließlich aus der Bestrebung heraus, seine Machtposition auszubauen, die sich entweder aus der Unternehmensstruktur oder auch rein subjektiv, aus der Anzahl der Mitarbeiter unter sich definiert. Dies kann dazu führen, dass er bewusst arbeitsintensivere Lösungen und Arbeitstechniken den effektiveren, effizienteren vorzieht. Auch bekannt als Empire building.
Empire building: durch sachlich nicht nachvollziehbare, nicht konstruktive Maßnahmen versucht ein einzelner seine Macht auszubauen bzw. zu erhalten. Dies kann Body bollooning sein, aber auch das ständige Beschuldigen anderer, gerade derer, die nicht mehr für die Unternehmung arbeiten, die Ausführung von pathologischer Politik, Diskreditierung, Mobbing und sonstige Fazetten, die nur darauf abzielen die eigene Position zu stärken bzw. den eigenen Status zu halten. Muster kennzeichnet sich auch dadurch aus dass die Person es vermeidet Verantwortung zu übernehmen und schriftliche Beweise für Vorkommnisse und Entscheidungen zu verhindern weiss. Somit muss er sich daran nicht messen lassen, was es auch einfacher macht, bei Misslingen eines Projektes die Verantwortung an einen anderen einfach weiterzudelegieren. Hier wird auch gerne jemand genommen der faktisch nur die Entscheidungen umgesetzt hat (wie ein Programmierer die Entscheidungen des Vorgesetzten oder ein Projektleiter die Anforderungen des Kunden umsetzt).
„Warmer Körper“ (englisch Warm body): Eine Person welche einen zweifelhaften oder keinen Beitrag zu einem Projekt leistet. Beispiel: in frühen Entwicklungsphasen sollten wenige Spezialisten das System entwerfen, erst anschließend können mehr Entwickler in einer größeren Anzahl das System umsetzen. Zuviele Entwickler in frühen Phasen sind warme Körper.

"Mushroom Management"
Single head of knowledge: Ein Individuum besitzt zu einer Software, zu einem Werkzeug oder ein anderes eingesetztes Medium als einziger unternehmensweit das Wissen. Zeugt häufig von fehlendem Wissensmanagement, mangelndem Austausch zwischen den Kollegen oder rudimentären Defiziten in der Organisation kann aber auch von dem Individuum bewusst angestrebt worden sein. Wenn das Individuum die Unternehmung verlässt nimmt er bildlich gesprochen das Wissen mit was für die Unternehmung sehr gefährlich ist, es blutet förmlich aus (bleeding). Muster kann durch Maßnahmen verhindert werden, z.B. durch Entwicklung nach XP und Teambuilding-Events zusammen mit Mitarbeiterbindung, -Motivation und Förderung der Identifikation mit der Unternehmung, um die Fluktuation zu minimieren.
Mushroom management: Mitarbeiter werden uninformiert und klein gehalten. Entfaltung und Selbstverwirklichung finden kaum statt. Die Analogie der Belegschaft zu einem Pilzfeld kennzeichnet sich dadurch aus, dass die Mitarbeiter bildlich mit Mist bedeckt und im Dunkeln gehalten werden, und, wenn sie zu gross geworden sind (zu viel Erfahrung, zu gute Leistungen), klein gemacht, unter Druck gesetzt oder gar entlassen werden. Diese Assoziation beinhaltet ferner die These, dass die Führung Entscheidungen fällt ohne die Spezialisten zu konsultieren bzw. die Belegschaft über diese Entscheidungen nicht informiert. Häufig ist auch zu beobachten, dass das Management die individuellen Fähigkeiten, Stärken, Schwächen und Rollen der Teammitglieder nicht kennt und manchmal sogar auch nicht kennen will (Personen werden gleichgeschaltet: Zugeben, dass jemand mehr kann als die andere macht ihn mächtiger, was vermieden werden soll).
„Noch ein Meeting wird es lösen“ (englisch Yet Another Meeting Will Solve It): Ein Meeting einzuberufen in einem verspäteten Projekt (ein Projekt mit Zeitverzug) erhöht nur noch mehr den Zeitverzug.
Net Negative Producing Programmer: Einen unperformanten, unproduktiven Entwickler aus einem Team zu entfernen kann die Projektproduktivität mehr erhöhen als einen guten Entwickler hinzufügen (und den unproduktiven belassen).
„Management nach Zahlen“ (englisch Management by numbers): Übermäßiger Schwerpunkt auf quantitativem Management, also Focus auf Kosten und vernachlässigen anderer Faktoren wie Qualität. Hier werden Programmierer gerne als "Gebrauchsgut" (englisch commodity) gesehen und als austauschbar betrachtet. Sehr kurzfristige Denkweise welche aussen vor lässt, dass fehlende Mitarbeitermotivation und/oder Mitarbeiterfluktuation dem Unternehmen mittel- bis langfristig wesentlich teurer kommt als eine kurzfristige Investition in diese. Hier ist auch der Begriff der Softwarefabrik (Software Factory) anzuführen, der Versuch die Softwareentwicklung zu automatisieren und den Programmierer als austauschbaren Produktionsfaktor zu betrachten. Dies berückichtigt allerdings nur unzureichend, dass die Softwareentwicklung zu einem großen Teil ein kreativer, künstlerischer Prozess ist, der Freiraum und optimalerweise auch hohe Entfaltungsmöglichkeit sowie (optimalerweise intrinsische) Motivation des Entwicklers voraussetzt. Ferner gilt es zu bedenken, dass Mitarbeiter über die Zeit viel Erfahrung bei der Arbeit an einem Produkt aufbauen, welche dem Unternehmen zu einem großen Teil verloren geht, wenn denn die Person die Unternehmung verlässt. Eine weitere Dimension ist die Unterscheidung zwischen Management nach "englischer Theorie" und Management nach "spanischer Theorie". Beim "englischen Führungsstil" geht das Management davon aus es gäbe nur eine feste Menge von Werten. Beim "spanischen Ansatz" geht man davon aus, dass Werte durch Genialität und Technologie geschaffen werden können. Die Analogie dieser beiden Wertetheorien beruht auf Beobachtungen wie die ehemaligen Kolonialmächte England und Spanien mit Ihren Kolonien umgingen, um maximalen Profit zu erlangen (die Spanier haben erkannt, dass ihr Vorgehen zu mehr Profit führt). Muster kann durch einen Balanced Scorecard-Ansatz oder Management nach "spanischer Wertetheorie" begegnet werden.
„Angst vor Erfolg“ (englisch Fear Of Success), oder auch: „Atmosphäre der Angst“: das Management sorgt für eine verängstigte, defensive Atmosphäre (wie ein Fussballteam welches nur das eigene Tor verteidigt ohne Bestrebungen zu haben ein eigenes Tor zu schiessen). In einer Kultur voller Angst kann kaum etwas Konstruktives entstehen. Auch etwas Gutes erstellende Personen brechen ihr Vorhaben ab, weil sie davon ausgehen sie verlieren sowieso oder die gute Lösung wird nicht honoriert bzw. als schlecht dargestellt. Unternehmen unter Angst wirken gelähmt und versäumen es neue Märkte und Lösungen aktiv anzugehen. Sowohl ganze Unternehmungen als auch Abteilungen oder einzelne Personen verlieren so ihre Wettbewerbsfähigkeit. Angst durch Erfolge aufzufallen und so den Argwohn der Kollegen oder des Managements auf sich zu ziehen (nicht selten sehen schlechte Manager in sehr guten Angestellten eine Gefahr, eine Konkurrenz auf ihre Position) verhindert ebenfalls, dass Mitarbeiter und Unternehmungen nicht ihre volle Leistungsfähigkeit abrufen. Typsiche Aussage: "Ich mache das heimlich. Es ist zwar die beste Lösung, ich will aber nicht, dass der Chef davon erfährt."

Angst
„Falscher System Architekt“ (englisch Faux System Architects): Das Management realisiert, dass es bei den Fähigkeiten der Programmierer große Unterschiede gibt. Es sucht sich eine Person aus, die vermeintlich überwältigende Fähigkeiten hat, sowohl bei der Software-Entwicklung als auch beim Umgang mit Leuten, gerade mit Personen, dessen Qualifikation unterdurchschnittlich ist. Die Person wird mit einer hohen Erwartungshaltung des Management eingesetzt, und ist häufig ein Architekt, oft aber auch ein anderer fachlicher Vorgesetzter. Bei der Auswahl werden interne Spezialisten nicht gefragt, das Management entscheidet selbst und alleine, obwohl es nur schwer selbst entscheiden kann, ob jemand ein guter Software-Entwickler ist. Lange Zeit läuft dies auch recht gut, da sich der vermeintliche Experte recht gut verkaufen kann, und sich auch verbal sehr geschickt auszudrücken weiß. Über die Zeit wird aber immer deutlicher, einerseits an der nicht eingetretenen Verbesserung der Software oder der gleichbleibenden schlechten Qualität der schlechten Programmierer, andererseits an einer Unzufriedenheit der guten Programmierer, dass die Erwartungen an den Architekten zu hoch waren. Er kann die blumigen, fast blinden Erwartungen in ihn nicht erfüllen.

Meta-Patterns

Programmer Experience Clumping

„Verklumpung erfahrener Programmierer“ (englisch Programmer Experience Clumping): Unerfahrene Programmierer sind meistens bereit für eine relativ geringe Vergütung für eine Unternehmung zu arbeiten (z.B. aus Unwissenheit oder um dort Erfahrung zu sammeln). Häufig werden in solchen Unternehmungen die Programmierer vom Management nicht geschätzt (meistens in Firmen wo "Management by numbers" vorherrscht). Es liegen schlechte Arbeitsbedingungen vor. Die unerfahrenen Programmierer können sich nicht weiterentwickeln. Erfahrene Spezialisten sehen was passiert und können dies objektiv und kritisch einschätzen.

"Zersetzung"

Diese werden den Arbeitsplatz wechseln, um eine Herausforderung anzunehmen, in der die Programmierung besser verstanden und gute Arbeit gewürdigt wird. Dies produziert einen Gruppierungseffekt, in dem sich unerfahrene Programmierer in der Unternehmung gruppieren bzw. dort verbleiben, und die erfahrenen Leute sich woanders gruppieren. Es kommt zu einer hohen Fluktuation, bei der immer mehr gute Leute das Unternehmen verlassen. Ohne die Führung der erfahrenen Kollegen können die unerfahrenen Entwickler oder neu eingestellte Rookies sich nicht verbessern. Ein Teufelskreis entsteht. Irgendwann weiß niemand im Unternehmen mehr, wie ein erfahrener Entwickler aussieht bzw. es fehlt der Benchmark: die unerfahrenen Entwickler merken immer weniger, dass sie eigentlich unerfahren sind.

Corrosion

„Zersetzung“ (englisch Corrosion): gewollte oder ungewollte Nutzung einer Vielzahl von Anti-Patterns aus allen Bereichen. Geht einher mit konsequenter Verteidigung des Vorgehens. Meist unsachlich und brachial, ohne Diskussion. Führt unweigerlich zu der Vermutung, der Anwendende möchte der Unternehmung oder dem Softwareprodukt grob fahrlässig Schaden zufügen bzw. dessen erfolgreiche, kostengünstige Einführung verhindern. Kann auch dadurch motiviert sein, dass der Anwendende eine andere involvierte Partei schaden möchte.

Siehe auch

Literatur

Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0201485672.
Kerievsky, Joshua (2004). Refactoring to Patterns. Addison-Wesley. ISBN 0321213351.
Tate, Bruce A. (2002). Bitter Java. Manning. ISBN 193011043X.
Tate, Bruce A. et al. (2003). Bitter EJB. Manning. ISBN 1930110952.
Brooks, F. (2003). Vom Mythos des Mann-Monats. Essays über Software-Engineering. mitp. ISBN 3-8266-1355-4.

Weblinks