AntiPatterns
description
Transcript of AntiPatterns
AntiPatterns
Einleitung
Übersicht
Einleitung
AntiPatterns: Poltergeist Swiss Army Knife Stovepipe Enterprise Golden Hammer
Reinvent the Wheel The Blop Email is Dangerous Spaghetti Code
Überblick
Identifizieren und kategorisieren der üblichen Fehler in der Softwareentwicklung.Wie kommt man von einem Problem zu einer schlechten Lösung?Sieht nach einer gute Idee aus, scheitert aber bei der Anwendung.Fokus auf häufig auftretende Softwareentwicklungs-Fehler.
Root Causes
Grundübel in der Softwareentwicklung, führen zu Budget- Überschreitung, Zeitverschiebung und scheiternden Projekten!
Haste -> Eile Apathy -> Teilnahmslosigkeit Narrow-mindedness -> Engstirnigkeit Sloth -> Faulheit Avarice -> Gier Ignorance -> Ignoranz Pride -> Hochmut/Stolz
Primal Forces
Anforderungen auf die bei der Entscheidungsfindung das Hauptaugenmerk gerichtet wird
Management of functionality Management of performance Management of change Management of IT resources Management of technology transfer
Einteilung I
Aus der Sicht des Entwicklers:Beschreiben Fehler die durch den Programmierer beim Lösen von Problemen verursacht werden.
Aus der Sicht des Software Architekten:Richten ihren Focus auf Probleme in der System Struktur,
ihren Konsequenzen und die passenden Lösungen.
Aus der Sicht des Software Managers:
Beschreiben Fehler und Lösungen während der Organisation von Software.
Einteilung IIDevelopment AntiPatterns
Architecture AntiPatterns
Project Management AntiPatterns
The BlobContinuous ObsolescenceLava FlowAmbiguous ViewpointFunctional DecompositionPoltergeistBoat AnchorGolden HammerDead EndSpaghetti CodeInput KludgeWalking through a
MinefieldCut-and-Paste
ProgrammingMushroom Managment
Autogenerated StovepipeStovepipe EnterpriseJumbleStovepipe SystemCover Your AssetsVendor Lock-InWolf TicketArchitecture By
ImplicationWarm BodiesDesign By CommitteeSwiss Army KnifeReinvent The WheelThe Grand Old Duke of
York
Blowhard JamboreeAnalysis ParalysisViewgraph EngineeringDeath By PlanningFear Of SuccessCorncobIntellectual ViolenceIrrational ManagementSmoke And MirrorsProject MismanagementThrow It Over The WallFire DrillThe FeudE-mail is Dangerous
TemplateÜbersicht
Name Auch bekannt als Auftreten Zitat/Anekdote
Beschreibung Charakteristik Konsequenzen
Ursachen und AusnahmenLösungBeispiel
Poltergeist
Poltergeist
Also Known As: Gypsy, Proliferation of Classes, Big Dolt Controller Class
„I`m not exactly sure what this class does, but it sure is important!“
Software Design Patterns: Anti-Pattern Helga Mesmer
„Gypsy Wagon“ that is there one day and gone the next.
Ein Poltergeist
PROCESS_TIMERPROCESS_TIMER
PEACHESPEACHES
CHOPPERCHOPPER
PEELERPEELER
WASHERWASHER
CANNERCANNER
PEACH_CANNER_CONTROLLER
PEACH_CANNER_CONTROLLER
CALENDARCALENDAR
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: Symptome
Kein Status
Kurze Lebensdauer
Wenig Verantwortung
Single-operation classes: Aufruf von Methoden oder anderen Klassen
Controller-Klassen
Suffix: _manager, _controller
PROCESS_TIMERPROCESS_TIMER
PEACHESPEACHES
CHOPPERCHOPPER
PEELERPEELER
WASHERWASHER
CANNERCANNER
PEACH_CANNER_CONTROLLER
PEACH_CANNER_CONTROLLER
CALENDARCALENDAR
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: SymptomeRedundante Navigation zwischen den einzelnen KlassenTransiente AssoziationenUnnötige Abstraktion dadurch nur schwer verständlich
Problem: No Exceptions
PROCESS_TIMERPROCESS_TIMER
PEACHESPEACHES
CHOPPERCHOPPER
PEELERPEELER
WASHERWASHER
CANNERCANNERPEACH_CANNER_
CONTROLLERPEACH_CANNER_
CONTROLLER
CALENDARCALENDAR
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: Folgerung
UnnötigVerbraucht zusätzliche ResourcenIneffizient
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: Ghostbusting
Poltergeist-Klassen aus der Hierarchie entfernenFehlende Funktionalität ersetzen indem man die Architektur korrigiert: die Kontrollfunktionen des Poltergeists den Klassen übertragen, die sie dann tatsächlich ausführen.
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: Lösungs-Beispiel
RAW_PEACHES_BINRAW_PEACHES_BIN CALENDARCALENDAR CANNED_PEACHES_BINCANNED_PEACHES_BIN
PEACH_CANNER_SYSTEMPEACH_CANNER_SYSTEM
MACHINEMACHINE
PEELERPEELERWASHERWASHER CHOPPERCHOPPER CANNERCANNER
SortRawPeaches()ScheduleJob()AssignTasks()AlocateRessources()...
SortRawPeaches()ScheduleJob()AssignTasks()AlocateRessources()...
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Poltergeist: Vorsicht!
Die 80%-Lösung des Blob ergibt oft einen Poltergeist: Coordinator-Class
Software Design Patterns: Anti-Pattern Helga MesmerSoftware Design Patterns: Anti-Pattern Helga Mesmer
Fragen?
Swiss Army Knife(Mini) Anti-Pattern
Übersicht
Software Architektur Mini Anti-Pattern
Auch bekannt als: Kitchen Sink
Häufigstes Auftreten: Objekt
+oeffneDose() : void+saegeBaum() : void+oeffneFlasche() : void+zieheKorken() : void+schneideBrot() : void+dreheSchraube() : void+schneidePapier() : void+streicheBrot() : void+zerlegeFisch() : void+scheideNaegel() : void+entferneEssensreste() : void+entschuppeFisch() : void+schneideFleisch() : void+entferneSpreisel() : void+erstecheAngreifer() : void+findeWeg() : void+leseUhrzeit() : void+schnitzeStock() : void+naeheStoff() : void+saegeAst() : void+schneideStoff() : void
SwissArmyKnife
BeschreibungCharakteristiken und
Konsequenzen:
Überladene Klassen / Interfaces
Implementation vieler Interfaces
Schwer zu verstehendes Design
Genauer Einsatzzweck / Einsatzweise unklar
Eigentlicher Einsatzzweck oft unzureichend
Debugging, Dokumentation und Wartbarkeit wird erschwert
Ursachen und Ausnahmen
Ursachen: Designern will alle erdenkbaren Einsatzmöglichkeiten
einer Klasse abdecken ( Eierlegende-Wollmilch-Sau)
Komplexe Interfaces und Standards wollen eingesetzt werden
Mangelnde Abstraktion oder Zweck für Klasse
Ausnahmen: Prototypen
Lösung für den Einsatz von Technologien
Bilden von Profilen: Def: Profile = Dokumentierte Konventionen zum
Einsatz einer Technologie Teilmenge der Signaturen der ursprünglichen
Interfaces Konventionen für zulässige Parameter Werte
Zwei unabhängige Entwickler können die selbe Technologie verwenden, und dabei eine Interoperabilität ihrer Software untereinander erreichen
Fazit
Ein Swiss-Army-Knife bringt im Software Design keinerlei Vorteile, nur Nachteile!
Vermeiden!
Stovepipe Enterprise
Übersicht
Name Stovepipe Enterprise
Auch bekannt als: Inseln der Automation
Auftreten Architekturpattern
Anekdote
“Kann ich meine eigene Insel (der Automation) haben?“
“Wir sind einzigartig!“
Allgemeine Form
Charakteristik
vielfache Systeme innerhalb eines Unternehmens werden auf jeder Ebene unabhängig von anderen bestimmt
- “Inseln der Automation“, isoliert von dem Rest des Unternehmens
Konsequenzen
inkompatible Technologie wenig Interoperabilität– auch bei gleichen Standards keine (wenig) Dokumentation geringe Erweiterbarkeit & Widerverwendbarkeit hohe Kosten
Ursachen
fehlende
– technologische Unternehmensstrategie
– Kooperation zw. Entwicklern
– Kooperation zw. Projekten
– Kompetenz
– horizontale Schnittstellen bei Systemintegration
Ausnahmen
Übernahme oder Fusion des Unternehmens
Gemeinsame Dienste (im Bankwesen:DB2 und Orakle)
Lösung
Lösung
Definition & Vereinheitlichung von:
1. Standards
2. Betriebsumgebungen (Produkte)
3. System-Profilen (Verwendung der Produkte)
Beispiel
Beispiel
Golden Hammer
Übersicht
NameGolden Hammer
Auch bekannt alsOld Yellar oder Head in Sand
Auftreten
System / Anwendungsebene
Anekdote
„Wenn das einzige Werkzeug, dass Du kennst ein Hammer ist, wird alles andere zum Nagel“
Beschreibung
CharakteristikEin Team hat besonders viele Erfahrungen mit einem Werkzeug in einer Lösungsweise oder einem Produkt. Jedes neue Produkt muss sich mit den Vorzügen eines Produktes messen. Die Nachteile werden dabei meist außer acht gelassen. Jedes Problem wird so angeschaut, als ob es mit diesem Werkzeug gelöst werden müsste.
Falsche Anwendung des bevorzugten Werkzeuges. Die Befürworter schlagen ein bestimmtes Produkt
immer als Lösung für Probleme vor auch wenn es bessere Produkte für diesen Zweck gibt.
Vorausgegangene Ausgaben (z.B. bei einer DB) dienen als Rechtfertigung für den Einsatz des Werkzeuges.
Beschreibung
KonsequenzenFür verschiedenste Konzepte wird immer das selbe Werkzeug verwendet.Produkte haben geringere Performance, und geringere Skalierbarkeit gegenüber vergleichbaren Produkten der KonkurrenzDie Systemarchitektur ist am besten über das verwendete Produkt zu beschreiben. Die Entwickler wollen die Spezifikationen stets so umstellen, das sie sich einfach mit diesen Werkzeugen verwirklichen lassen.Die Entwickler wollen aus der Spezifikation alles streichen, wo das Werkzeug nicht geeignet ist.Neue Entwicklungen bauen sehr stark auf einem bestimmten Produkt oder einen bestimmten Hersteller auf.
Beispiel
C(++) ist die einzig wahre Sprache zu was soll Java gut sein
Man kann nur mit Microsoft Office richtig arbeiten.
XML-DB Integration von Microsoft. Was nicht relational ist ist nicht erlaubt.
Lösung
Ständige Erforschung alternativer Lösungsansätze und Veranschaulichung der Vor- und Nachteile.Softwaresysteme müssen mit wohl definierten Grenzen versehen werden, damit einzelne Teile eigenständig herausgelöst werden können. Softwareentwickler müssen immer auf dem neuesten Stand der Entwicklung sein, sowohl auf Organisationsebene als auch im Bereich der Software Technologie als ganzes.Anheuern von Leuten aus fremden Firmen oder anderen Fachgebieten. Das Management muss in „Professionelles Softwareentwickeln“ investieren und Mitarbeiter belohnen, die Prozesse verbessern.
Reinvent The WheelAnti-Pattern
Übersicht
Software Architektur Anti-Pattern
Auch bekannt als: Design in a Vacuum Greenfield System
Auftreten: System
Zitat:„Unser Problem ist einzigartig“
Hintergrund Reinvent Reuse
Software Reuse <--> Design Reuse: Software Reuse:
Erstellung, Verwendung und Integration einer Bibliothek von wiederverwendbaren Komponenten
Ergebnis: mäßige Wiederverwendbarkeit, Entwicklungsaufwand für Integration nötig
Design Reuse: Wiederverwendung einer Architektur und Software
Interfaces Erfordert Identifikation von horizontaler Komponenten Ergebnis: gute Wiederverwendbarkeit, kein
Entwicklungsaufwand für Integration nötig
Beschreibung
Charakteristiken und Konsequenzen: „Closed System“ Architektur Funktionen vorhandener kommerzieller Software
wird repliziert Architektur ging durch viele Entwicklungs-Zyklen,
bevor sie einsatzfähig wurde Unausgereifte und instabile Architekturen Hoher Aufwand Gewünschte Funktionalität kann u.U. an den Kunden
nicht geliefert werden (oder nicht rechzeitig)
Ursachen und Ausnahmen
Ursachen: Top-Down Analyse und Design führen zu neuen
Architekturen und Individual-Software Annahme eines „Greenfields“:
Keine „legacy systems“ Software von Grund auf entwickeln Isoliertes Einzel-System
Keine Kommunikation und Technologie-Transfer zwischen einzelnen Entwicklungs-Teams bzw. Abteilungen
Fehlen eines expliziten Architektur Prozesses Schlechte Risiko- und Kosten-Analyse
Ursachen und Ausnahmen
Ausnahmen: In einer Forschungs-Umgebung In der allgemeinen Software-Entwicklung, um die
Koordinations-Kosten zu minimieren, wenn Entwickler mit unterschiedlichen Fähigkeiten an unterschiedlichen Orten arbeiten
Lösungen
Architecture Mining: Extrahieren von Design Informationen vorhandener
Designs und Verwendung dieser Informationen in der eigenen OO-Architektur
Bottom-Up Design Prozess OO Architekturen werden robust, Hersteller-
Unabhängig, Wiederverwendbar und Erweiterbar
Architecture Farming: Erstellen eines Design aus den Anforderungen, im
Entwicklungsprozesse Design spiralförmig erweitern und verändern
Top-Down Design Prozess „Reinvent“ der Design Informationen
Fazit
Das Reinvent the Wheel für zu erhöhten Kosten und schlechteren Designs
Vermeiden!
The Blob
Übersicht
Name The Blop
Auch bekannt als: Winnebago, Klasse des Gottes
Auftreten Softwarepattern
Anekdote
“Das ist die Klasse, die das Herz unserer Architektur ist.”
Allgemeine Form
Beschreibung
Charakteristik
Einzelne Klasse mit einer großen Zahl von Attributen, Operationen, oder beiden
Eine ungleiche Sammlung von Attributen ohne Beziehung und in einer einzelnen Klasse kurz zusammengefassten Operationen
A single controller class with associated simple, data−object classes.
Beschreibung
Konsequenzen unvereinbare Fachsprache, Annäherungen, und
Technologien zwischen Unternehmenssystemen Spröde, monolithische System-Architekturen und
undokumentierte Architekturen Unfähigkeit, Systeme zu erweitern, um
Geschäftsbedürfnisse zu unterstützen Falscher Gebrauch eines Technologiestandards. Unfähigkeit von Systemen sich sogar bei der Verwendung
der gleichen Standards zu verstehen Übermäßige Wartungskosten wegen sich ändernden
Geschäftsvoraussetzungen
Email is Dangerous
Übersicht
Name: Email is Dangerous
Auch bekannt als:Blame-Storming
Auftreten
In allen Bereichen
Beschreibung
CharakteristikE-Mail hat eine außerordentlich starke Bedeutung in der betrieblichen Kommunikation
In E-Mails steht alles von Scherzen über allgemeine Information und normaler betrieblicher Kommunikation bis hin geheimen Daten.
E-Mail hat keinerlei Sicherungsfunktion. Durch das Store and Foreward Prinzip erhält jeder Mailserver eine unverschlüsselte Kopie zum weiterleiten.
Beschreibung
KonsequenzenEine vertrauliche Nachricht endet oft bei dem Empfänger, den man am wenigsten wünscht (Boss, Konkurrenz)
Eine E-Mail kann permanent gespeichert werden. Jemand kann einen leicht darauf festnageln.
Eine E-Mail kann komplett falsch interpretiert werden, viel stärker als bei persönlichem oder telefonischem Kontakt
Eine E-Mail kann an sehr viele Leute gleichzeitig weitergeleitet werden.
Email eignet sich nicht um komplizierte Sachverhalte zu erörtern. Da oft Fehlinterpretationen auftreten
Beispiel
Beschwerde über Chef landet bei ihm selber
Kontoaufstellung von Kunden per Email kann potentiell von jedem Mail Server gelesen und weiterverbreitet werden.
Ironie in Mail wird ernst genommen.
Lösung
Generell sollte E-Mail im betrieblichen Umfeld mit Vorsicht behandelt
werden.Emails sollten nicht für folgende Themen verwendet
werden:KritikVertrauliche DatenPolitisch Inkorrekte ThemenStrafbare Äußerungen
Ausnahmen können gemacht werden, wenn die E-Mails verschlüsselt und signiert werden.
Spaghetti Code
Spaghetti Code
NameSpaghetti Code
AuftretenApplication
Zitat„Oh je! Was für ein Durcheinander!“„Da schreib ich den Code lieber noch mal neu bevor ich
den abändere“
Spaghetti Code
CharakteristikLange Methoden RümpfeEigentlichem Entwickler fällt es schwer den Überblick zu bewahrenWas passiert wenn der Entwickler das Projekt verlässt?Wenig Objekte mit lang implementierten Methoden
KonsequenzenSchwer zu wartenObjekte eigenen sich nicht zur WiederverwertungVorteile der OO Sprachen gehen verlorenKosten für die Wartung des Codes sind größer als die Kosten die Software neu zu entwickeln
Spaghetti Code
UrsachenKeine Erfahrung in OO EntwicklungKein Design vor der ImplementierungResultat von Isolation des Entwicklers
AusnahmenSchlüssige Interfaces, nur die Implementierung ist SpaghettiLebenszeit ist kurz und die Komponente ist klar vom Rest des Systems getrennt
Spaghetti Code
Lösung
Umstrukturieren
Neu entwickeln
Am besten nicht aufkommen lassen
Mitwirkende
Marianna TatovaHelga Debora MessmerMirko BleyhDaniel HaagFabian Mielke