Anti Patterns Einleitung bersicht Einleitung Anti Patterns n

Anti. Patterns Einleitung

Übersicht Einleitung Anti. Patterns: n n n n 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! n n n n 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 n n n Management Management of of of functionality performance change IT resources 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 II Development Anti. Patterns Architecture Anti. Patterns Project Management Anti. Patterns w. The Blob w. Continuous Obsolescence w. Lava Flow w. Ambiguous Viewpoint w. Functional Decomposition w. Poltergeist w. Boat Anchor w. Golden Hammer w. Dead End w. Spaghetti Code w. Input Kludge w. Walking through a Minefield w. Cut-and-Paste Programming w. Mushroom Managment w. Autogenerated Stovepipe w. Stovepipe Enterprise w. Jumble w. Stovepipe System w. Cover Your Assets w. Vendor Lock-In w. Wolf Ticket w. Architecture By Implication w. Warm Bodies w. Design By Committee w. Swiss Army Knife w. Reinvent The Wheel w. The Grand Old Duke of York w. Blowhard Jamboree w. Analysis Paralysis w. Viewgraph Engineering w. Death By Planning w. Fear Of Success w. Corncob w. Intellectual Violence w. Irrational Management w. Smoke And Mirrors w. Project Mismanagement w. Throw It Over The Wall w. Fire Drill w. The Feud w. E-mail is Dangerous

Template Übersicht n n Name Auch bekannt als Auftreten Zitat/Anekdote Beschreibung n n Charakteristik Konsequenzen Ursachen und Ausnahmen Lösung Beispiel

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!“ „Gypsy Wagon“ that is there one day and gone the next. Software Design Patterns: Anti-Pattern Helga Mesmer

Ein Poltergeist PROCESS_TIMER CANNER PEACHES PEACH_CANNER_ CONTROLLER WASHER CHOPPER PEELER CALENDAR Software Design Patterns: Anti-Pattern Helga Mesmer

Poltergeist: Symptome PROCESS_TIMER CANNER PEACHES PEACH_CANNER_ CONTROLLER WASHER CHOPPER PEELER Kein Status Kurze Lebensdauer CALENDAR Wenig Verantwortung Single-operation classes: Aufruf von Methoden oder anderen Klassen Controller-Klassen Suffix: _manager, _controller Software Design Patterns: Anti-Pattern Helga Mesmer

Poltergeist: Symptome Redundante Navigation zwischen den einzelnen Klassen Transiente Assoziationen Unnötige Abstraktion dadurch nur schwer verständlich PROCESS_TIMER CANNER PEACHES PEACH_CANNER_ CONTROLLER WASHER CHOPPER PEELER CALENDAR Problem: No Exceptions Software Design Patterns: Anti-Pattern Helga Mesmer

Poltergeist: Folgerung Unnötig Verbraucht zusätzliche Resourcen Ineffizient Software Design Patterns: Anti-Pattern Helga Mesmer

Poltergeist: Ghostbusting Poltergeist-Klassen aus der Hierarchie entfernen Fehlende 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 Mesmer

Poltergeist: Lösungs-Beispiel RAW_PEACHES_BIN CALENDAR CANNED_PEACHES_BIN PEACH_CANNER_SYSTEM Sort. Raw. Peaches() Schedule. Job() Assign. Tasks() Alocate. Ressources(). . . MACHINE WASHER Software Design Patterns: Anti-Pattern PEELER CHOPPER CANNER Helga Mesmer

Poltergeist: Vorsicht! Die 80%-Lösung des Blob ergibt oft einen Poltergeist: Coordinator-Class Fragen? Software Design Patterns: Anti-Pattern Helga Mesmer

Swiss Army Knife (Mini) Anti-Pattern

Übersicht Software Architektur Mini Anti-Pattern Auch bekannt als: n Kitchen Sink Häufigstes Auftreten: n Objekt

Beschreibung Charakteristiken und Konsequenzen: n n n Ü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: n Designern will alle erdenkbaren Einsatzmöglichkeiten einer Klasse abdecken ( Eierlegende-Wollmilch-Sau) n Komplexe Interfaces und Standards wollen eingesetzt werden n Mangelnde Abstraktion oder Zweck für Klasse Ausnahmen: n Prototypen

Lösung für den Einsatz von Technologien Bilden von Profilen: n Def: Profile = Dokumentierte Konventionen zum Einsatz einer Technologie n Teilmenge der Signaturen der ursprünglichen Interfaces n 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 n Stovepipe Enterprise Auch bekannt als: n Inseln der Automation Auftreten n 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 n fehlende – technologische Unternehmensstrategie – Kooperation zw. Entwicklern – Kooperation zw. Projekten – Kompetenz – horizontale Schnittstellen bei Systemintegration

Ausnahmen Übernahme oder Fusion des Unternehmens Gemeinsame Dienste (im Bankwesen: DB 2 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 Name Golden Hammer Auch bekannt als Old 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 Charakteristik Ein 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 Konsequenzen Für verschiedenste Konzepte wird immer das selbe Werkzeug verwendet. Produkte haben geringere Performance, und geringere Skalierbarkeit gegenüber vergleichbaren Produkten der Konkurrenz Die 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 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 Wheel Anti-Pattern

Übersicht Software Architektur Anti-Pattern Auch bekannt als: n Design in a Vacuum n Greenfield System Auftreten: n System Zitat: „Unser Problem ist einzigartig“

Hintergrund Reinvent Reuse Software Reuse <--> Design Reuse: n n Software Reuse: w Erstellung, Verwendung und Integration einer Bibliothek von wiederverwendbaren Komponenten w Ergebnis: mäßige Wiederverwendbarkeit, Entwicklungsaufwand für Integration nötig Design Reuse: w Wiederverwendung einer Architektur und Software Interfaces w Erfordert Identifikation von horizontaler Komponenten w Ergebnis: gute Wiederverwendbarkeit, kein Entwicklungsaufwand für Integration nötig

Beschreibung Charakteristiken und Konsequenzen: n „Closed System“ Architektur n Funktionen vorhandener kommerzieller Software wird repliziert n Architektur ging durch viele Entwicklungs-Zyklen, bevor sie einsatzfähig wurde n Unausgereifte und instabile Architekturen n Hoher Aufwand n Gewünschte Funktionalität kann u. U. an den Kunden nicht geliefert werden (oder nicht rechzeitig)

Ursachen und Ausnahmen Ursachen: n Top-Down Analyse und Design führen zu neuen Architekturen und Individual-Software n Annahme eines „Greenfields“: w Keine „legacy systems“ w Software von Grund auf entwickeln w Isoliertes Einzel-System n n n Keine Kommunikation und Technologie-Transfer zwischen einzelnen Entwicklungs-Teams bzw. Abteilungen Fehlen eines expliziten Architektur Prozesses Schlechte Risiko- und Kosten-Analyse

Ursachen und Ausnahmen: n In einer Forschungs-Umgebung n 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: n Extrahieren von Design Informationen vorhandener Designs und Verwendung dieser Informationen in der eigenen OOArchitektur n Bottom-Up Design Prozess OO Architekturen werden robust, Hersteller-Unabhängig, Wiederverwendbar und Erweiterbar Architecture Farming: n Erstellen eines Design aus den Anforderungen, im Entwicklungsprozesse Design spiralförmig erweitern und verändern n Top-Down Design Prozess n „Reinvent“ der Design Informationen

Fazit Das Reinvent the Wheel für zu erhöhten Kosten und schlechteren Designs Vermeiden!

The Blob

Übersicht Name n The Blop Auch bekannt als: n Winnebago, Klasse des Gottes Auftreten n Softwarepattern

Anekdote “Das ist die Klasse, die das Herz unserer Architektur ist. ”

Allgemeine Form

Beschreibung Charakteristik n n n 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 n n n unvereinbare Fachsprache, Annäherungen, und Technologien zwischen Unternehmenssystemen Spröde, monolithische System-Architekturen 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 Charakteristik E-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 Konsequenzen Eine 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: Kritik Vertrauliche Daten Politisch Inkorrekte Themen Strafbare Äußerungen Ausnahmen können gemacht werden, wenn die E-Mails verschlüsselt und signiert werden.

Spaghetti Code

Spaghetti Code Name Spaghetti Code Auftreten Application Zitat „Oh je! Was für ein Durcheinander!“ „Da schreib ich den Code lieber noch mal neu bevor ich den abändere“

Spaghetti Code Charakteristik Lange Methoden Rümpfe Eigentlichem Entwickler fällt es schwer den Überblick zu bewahren Was passiert wenn der Entwickler das Projekt verlässt? Wenig Objekte mit lang implementierten Methoden Konsequenzen Schwer zu warten Objekte eigenen sich nicht zur Wiederverwertung Vorteile der OO Sprachen gehen verloren Kosten für die Wartung des Codes sind größer als die Kosten die Software neu zu entwickeln

Spaghetti Code Ursachen Keine Erfahrung in OO Entwicklung Kein Design vor der Implementierung Resultat von Isolation des Entwicklers Ausnahmen Schlüssige Interfaces, nur die Implementierung ist Spaghetti Lebenszeit 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 Tatova Helga Debora Messmer Mirko Bleyh Daniel Haag Fabian Mielke