Ich bin kürzlich bei Wikipedia auf einen Artikel gestoßen den man meiner Meinung nach der Welt nicht vorenthalten sollte. Wem Ausserirdische Spinnen, Warme Leichen oder eine Sumo-Hochzeit ein Begriff sind weiß genau wovon ich spreche. Es geht um Anti-Patterns, also Negativ Beispiele für immer wieder auftretende Aufgabenstellungen. Das Wissen um eine Aufgabe effizient zu lösen erreicht man häufig durch die Suche nach etablierten Lösungen. Ich persönlich erachte es aber als schwierig, eine gute von einer schlechten Lösung zu unterscheiden, wenn man die Probleme und Stolperfallen nicht kennt und den Weg den man einschlägt eigentlich nicht objektiv bewerten kann. Anti Patterns geben hier einen Anhaltspunkt und decken alt bekannte Probleme auf.
Hier ein Auszug meiner Lieblings Patterns
Das Brookssche Gesetzt:
Mitarbeiter zu einem verspäteten Projekt hinzuzufügen verspätet das Projekt nur noch weiter
Gottobjekt:
Das kennen wir wohl alle. Man schreibt und schreibt. Kaum ist released wird natürlich noch ein wichtiges Feature benötigt und man versucht es noch irgendwie in die Implementierung reinzuquetschen. Auf einmal ensteht aus dem nichs ein Gottobjekt. D.h. in Objekt, das zu viel weiß respektive zu viel macht.
Ein Favorit in vielen Projekten ist natürlich auch die
Zwiebel:
Neue Funktionalität wird um (oder über) die alte gelegt. Dies kommt häufig vor wenn ein Entwickler ein Programm erweitern soll, welches er nicht geschrieben hat. Der Entwickler möchte (ja ja ja so sind se) 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.
Abschließend zu sagen verlassen wir uns doch einfach auf altbewährtes und gehen den bewährten Weg…
Noch ein Meeting mehr wird es lösen: Ein Meeting einzuberufen in einem verspäteten Projekt erhöht nur noch mehr den Zeitverzug (englisch Yet Another Meeting Will Solve It).
Quelle:
http://de.wikipedia.org/wiki/Anti-Pattern