1 / 68

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.

tino
Download Presentation

AntiPatterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AntiPatterns Einleitung

  2. Übersicht • Einleitung • AntiPatterns: • Poltergeist • Swiss Army Knife • Stovepipe Enterprise • Golden Hammer • Reinvent the Wheel • The Blop • Email is Dangerous • Spaghetti Code

  3. Ü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.

  4. 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

  5. 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

  6. 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.

  7. Einteilung II

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

  9. Poltergeist

  10. PoltergeistAlso 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

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

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

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

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

  15. 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 Software Design Patterns: Anti-Pattern Helga Mesmer

  16. RAW_PEACHES_BIN CALENDAR CANNED_PEACHES_BIN PEACH_CANNER_SYSTEM SortRawPeaches() ScheduleJob() AssignTasks() AlocateRessources() ... MACHINE WASHER PEELER CHOPPER CANNER Poltergeist: Lösungs-Beispiel Software Design Patterns: Anti-Pattern Helga Mesmer Software Design Patterns: Anti-Pattern Helga Mesmer

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

  18. Swiss Army Knife(Mini) Anti-Pattern

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

  20. Beschreibung Charakteristiken 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

  21. 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

  22. 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

  23. Fazit Ein Swiss-Army-Knife bringt im Software Design keinerlei Vorteile, nur Nachteile!  Vermeiden!

  24. Stovepipe Enterprise

  25. Übersicht • Name • Stovepipe Enterprise • Auch bekannt als: • Inseln der Automation • Auftreten • Architekturpattern

  26. Anekdote “Kann ich meine eigene Insel (der Automation) haben?“ “Wir sind einzigartig!“

  27. Allgemeine Form

  28. Charakteristik • vielfache Systeme innerhalb eines Unternehmens werden auf jeder Ebene unabhängig von anderen bestimmt - “Inseln der Automation“, isoliert von dem Rest des Unternehmens

  29. Konsequenzen • inkompatible Technologie • wenig Interoperabilität – auch bei gleichen Standards • keine (wenig) Dokumentation • geringe Erweiterbarkeit & Widerverwendbarkeit • hohe Kosten

  30. Ursachen • fehlende – technologische Unternehmensstrategie – Kooperation zw. Entwicklern – Kooperation zw. Projekten – Kompetenz – horizontale Schnittstellen bei Systemintegration

  31. Ausnahmen • Übernahme oder Fusion des Unternehmens • Gemeinsame Dienste (im Bankwesen:DB2 und Orakle)

  32. Lösung

  33. Lösung • Definition & Vereinheitlichung von: 1. Standards 2. Betriebsumgebungen (Produkte) 3. System-Profilen (Verwendung der Produkte)

  34. Beispiel

  35. Beispiel

  36. Golden Hammer

  37. Übersicht Name • Golden Hammer Auch bekannt als • Old Yellar oder Head in Sand Auftreten • System / Anwendungsebene

  38. Anekdote • „Wenn das einzige Werkzeug, dass Du kennst ein Hammer ist, wird alles andere zum Nagel“

  39. 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.

  40. 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.

  41. 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.

  42. 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.

  43. Reinvent The WheelAnti-Pattern

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

  45. 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

  46. 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)

  47. 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

  48. 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

  49. 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

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

More Related