Sind Designmuster verpönt?

Ich hatte ein Gespräch mit einem unserer leitenden Entwickler, der seit 20 Jahren im Geschäft ist. Er ist in Ontario ziemlich bekannt für einen Blog, den er schreibt.

Das Seltsame ist, was er mir erzählt hat: Er sagte, dass es einen Code gibt, mit dem man sich quälen kann, weil er aus einem Lehrbuch stammt und die reale Welt nicht berücksichtigt. Das Hinzufügen eines neuen Feldes zur Benutzeroberfläche / Datenbank / Datenebene dauert 2-3 Stunden, während es in seinem Code 30 Minuten dauert.

Die andere Sache ist auch, dass er Designmuster vermeidet, weil die meisten Programmierer sie nicht verstehen und sie aus Wartungssicht nicht gut sind.

Dann gibt es auch die Idee, dass die meisten Webentwickler in Kanada es vorziehen, ihr Datenmodell von den Data Layer-Klassen zu erben, anstatt es isoliert zu halten. Ich fragte ihn: "Ist es nicht Industriestandard, dass das Modell von der Datenschicht getrennt ist?" Er sagte manchmal, aber die meisten Leute hier ziehen es vor, das nicht zu tun, weil es zu viel Arbeit ist.

Es hört sich so an, als wäre seine Argumentation, dass er nicht mit Best Practices codiert, ein Wartungs-Albtraum, den nur wenige unserer Mitarbeiter (außer mir) verstehen und mit dem er nur langsam arbeitet, wenn Sie in wenigen Tagen neue Funktionen oder Felder herausbringen müssen. Zeit.

Es ist so seltsam, eine Meinung wie diese zu hören, wenn man bedenkt, dass Stack Overflow die meisten Leute dazu ermutigt, Industriestandards zu befolgen. Ist das Problem, dass wir ständig gezwungen sind, innerhalb weniger Tage neue Felder und Features zu erzeugen, dass es nicht möglich ist, ein solides Muster abzuleiten, das flexibel genug ist? Das scheint der Kern dessen zu sein, was ich daraus verstehe.

Was halten Sie von diesen Aussagen?

Dies sind die Worte von jemandem, der Erfolg hat und Leute ignoriert, die versuchen, ihm zu sagen, was er im Musterjargon tun soll, den er nicht versteht.

Entwurfsmuster und Best Practices sind nicht dasselbe. Einige Leute denken, dass sie es sind und treiben Leute an, die wissen, was sie verrückt machen. Auch wenn sie den richtigen Namen für das, was sie tun, nicht kennen.

Entwurfsmuster existierten, bevor sie Namen hatten. Wir haben ihnen Namen gegeben, um das Gespräch zu erleichtern. Ein Muster mit einem Namen macht es nicht gut. Es macht es zu einer erkennbaren Sache.

Dieser Typ verwendet wahrscheinlich Muster, von denen keiner von euch jemals gehört hat. Das ist in Ordnung, bis Sie mit ihm darüber sprechen müssen, wie etwas getan wird. Entweder muss er lernen, wie man mit Ihnen spricht, oder Sie müssen lernen, wie man mit ihm spricht. Hat nichts damit zu tun, wer "richtig" ist.

Viele Entwurfsmuster, wie Sie und Ihr Freund sie beschreiben, sind wirklich nur Umgehungslösungen für Mängel in Programmiersprachen . Verwenden Sie eine ausdrucksstärkere Programmiersprache, und die meisten dieser Entwurfsmuster werden nicht mehr benötigt.

Da gute Entwurfsmuster erforderlich sind, um vielen möglichen Verwendungsszenarien gerecht zu werden, sind sie in der Regel überentwickelt. Überentwickelter Code hat Kosten: Sie müssen ihn lesen, verstehen, was er tut, und verstehen, wie er im Kontext des gesamten Softwaresystems funktioniert. Folglich müssen Sie wie bei jeder anderen Softwareentwicklungstechnik die Technik anhand der Kosten für die Verwendung der Technik bewerten und entscheiden, ob der Nutzen die Kosten übersteigt.

Wenn alle anderen Dinge gleich sind, ist weniger Code immer besser. Ich habe vielschichtige Architekturen durchlaufen, bei denen man buchstäblich drei bis sechs Sprünge durch mehrere Projekte machen muss, um irgendeinen interessanten Code zu finden , dh Code, der tatsächlich etwas anderes als das Hinzufügen von Overhead bewirkt.

Bekannte Softwaremuster sollen Ihnen ein gemeinsames Vokabular vermitteln, mit dem Sie Entwurfsstrategien kommunizieren können. Leider verstehen viele Softwareentwickler das Softwaremuster-Vokabular nicht gut genug, um es ordnungsgemäß auf ihre Programmierprobleme anzuwenden. Unerfahrene Entwickler sehen diese Muster in der Domäne von Experten. Sie wollen als Experten gesehen werden und versuchen daher, die Muster zu früh zu lernen und anzuwenden, bevor sie dazu bereit sind. Stattdessen sollten sie sich wirklich darauf konzentrieren, zuerst die Grundlagen der Programmierung zu lernen und dann zu versuchen, das Problem zu lösen, das jedes Muster für sich löst. Wenn sie dies tun, können sie die Muster viel besser verstehen und korrekt anwenden.

Stackoverflow.SE und Programmierer.SE ermutigen die Leute hauptsächlich, Best Practices wie SOLID und nicht Industriestandards zu befolgen . Und ob Sie es glauben oder nicht, der De-facto-Industriestandard ist oft die "Big Ball of Mud" -Architektur - im Ernst.

Um Ihre Frage direkt zu beantworten: Das Problem mit Entwurfsmustern ist ähnlich wie bei der Vererbung - viele mittelmäßige Entwickler überbeanspruchen sie, was mit einem gewissen Risiko verbunden ist, überentwickelten, schwer zu wartenden Code zu erstellen. Aber die Antwort darauf ist sicherlich, die Verwendung von Entwurfsmustern (oder Vererbung) nicht vollständig zu vermeiden oder zu verbieten. Die Antwort ist, zu lernen, diese Werkzeuge in Situationen zu verwenden, in denen sie sinnvoll sind und nur dort. Und das ist völlig unabhängig davon, ob man "agil" arbeitet oder nicht.

1. Entwurfsmuster sind nur Namen, mit denen Ideen kommuniziert werden. Ich habe oft Dinge gemacht, die später einen Namen hatten. Somit gibt es keinen "Entwurfsmusterweg" im Gegensatz zu einem "Nicht-Entwurfsmusterweg".

2. Entwurfsmuster sind Richtlinien. Jeder von ihnen hat Vor- und Nachteile. Der Schlüssel besteht nicht darin, das Muster zu lernen und es dort anzuwenden, wo es passt, sondern die Idee des Musters, die Vor- und Nachteile zu verstehen und daraus Inspiration für die Lösung Ihres Problems zu gewinnen.

3. Jedes bewährte Verfahren und jede Richtlinie kann ignoriert werden, wenn ein ausreichender Grund vorliegt. Zu den gültigen Gründen gehören die Entwicklungszeit und die Erwartungen an die Anwendung. Ich bin mir zum Beispiel bewusst, dass es schlecht ist, Werte fest zu codieren (dummes Beispiel), aber für einen Proof of Concept können die Vorteile die Kosten überwiegen (in diesem Fall meistens die Entwicklungszeit). Wenn jedoch eine solche Entscheidung getroffen wird, kann sie nach hinten losgehen, und irgendwann ist möglicherweise ein Refactoring erforderlich.

Um der Suppe eine weitere Metapher hinzuzufügen, sind Entwurfsmuster Clippy, der Microsoft Office-Helfer. "Sie tun anscheinend dasselbe mit einer ganzen Reihe von Dingen. Kann ich Ihnen dabei helfen, indem ich Ihnen Iterator oder Besucher anbiete?"

Eine gute Beschreibung dieser Muster zeigt an, wann es nützlich ist, etwas so zu machen, wie es schon oft gemacht wurde, welche Fehler Sie beim ersten Versuch machen und welche gängigen Methoden gefunden wurden, um diese Fehler zu vermeiden . Sie lesen das Entwurfsmuster (oder überprüfen es aus dem Speicher) und können dann mit Ihrer Arbeit fortfahren. Was Sie nicht tun können, ist, nur mit Clippy und Assistenten auszukommen.

Unerfahrene Menschen können Fehler machen und Code schreiben, der die Realität nicht berücksichtigt, wenn sie glauben, dass ihre Liste der Entwurfsmuster eine vollständige Liste aller möglichen Ansätze zur Lösung von Problemen in der Software ist, und versuchen, Code durch Verknüpfen von Entwurf zu entwerfen Muster, bis es fertig ist. Eine andere schlechte Taktik, die in der Natur beobachtet wird, besteht darin, ein Designmuster in eine Situation zu hupen, für die es nicht wirklich geeignet ist, auf der Grundlage, dass das Designmuster "Best Practice" ist. Nein, es kann für die Klasse von Problemen, die es tatsächlich löst , die beste Praxis sein oder nicht , aber es ist sicherlich nicht die beste Praxis für Probleme, die es nicht löst, oder für Probleme, die es nur löst, indem es unnötige Komplexität einführt, wenn es eine einfachere Lösung gibt .

Natürlich ist es auch möglich, dass jemand ein Muster auf der Grundlage von YAGNI vermeidet, erkennt, dass er es benötigt, und tastet nach der normalen Lösung. Dies ist in der Regel (aber nicht immer) schlimmer, als die Anforderung von Anfang an zu realisieren. Deshalb ist es auch in einer agilen Entwicklung frustrierend, wenn vollständig vorhersehbare Anforderungen nicht frühzeitig erkannt werden. Ich kann nicht der einzige C ++ - Programmierer gewesen sein, der sehr amüsiert war, dass Java generische Container anfangs als unnötig komplex zurückwies und sie später wieder anschloss.

Es ist also mit ziemlicher Sicherheit ein Fehler, das Schreiben eines Iterators grundsätzlich zu vermeiden, da Sie Entwurfsmuster lieber vermeiden.

Das Hinzufügen eines neuen Felds zur Benutzeroberfläche / Datenbank / Datenebene dauert 2-3 Stunden, wobei es wie in seinem Code 30 Minuten dauert.

Dem kann man nicht wirklich widersprechen: Durch diese Metrik ist sein Design weitaus besser als das der anderen. Ob das daran liegt, dass er Designmuster vermieden hat, ist fraglich, ich denke, es ist wahrscheinlicher, weil er die richtigen "realen" Probleme beim Entwerfen berücksichtigte und mit dem Vorteil der Erfahrung besser in seinem Job ist als jemand, der nur mit einem Lehrbuch und bewaffnet ist hohe Ideale.

Daher erkannte er, dass jedes Muster, bei dem Sie zum Hinzufügen eines Felds viele verschiedene Punkte im Code berühren müssen, ein schlechtes Muster für den Job ist. "Machen Sie das Hinzufügen von Feldern einfach", und er hat diese Muster nicht verwendet. Layer-Architekturen können in der Tat darunter leiden, und es ist falsch, Entwurfsmuster zu verwenden, ohne deren Nachteile zu berücksichtigen.

Wie lange dauert es dagegen, eine neue Benutzeroberfläche in seinem Design zu schreiben, und wie lange dauert es in einer geschichteten Architektur? Wenn das Projekt ihn dazu aufforderte, ständig neue Benutzeroberflächen über ein festes Datenmodell zu erstellen und bereitzustellen, anstatt ständig Felder hinzuzufügen, hätte er hoffentlich stattdessen dafür entworfen. Oder auch. Bei all seinen Vorteilen heißt es jedoch leider nicht, dass Sie nie wieder einen Kompromiss eingehen müssen, wenn Sie sagen, dass wir agil sind!

Die Auswahl aus einem Menü mit Designmustern kann Sie sicherlich davon abhalten, über die wichtigsten Aspekte nachzudenken. Das Erkennen, wann Sie einen Besucher schreiben, und das Dokumentieren oder Benennen als "Besucher", um den Lesern einen schnellen Zugriff zu ermöglichen, steht jedoch nichts im Wege. "Das ist ein Besucher" zu schreiben, anstatt es richtig zu dokumentieren, ist ein schrecklicher Fehler, aus dem Grund, den Ihr leitender Entwickler angibt - Programmierer werden es nicht verstehen. Selbst Programmierer, die wissen, was ein Besucher ist, benötigen mehr Informationen als nur "das ist ein Besucher".

Ihr Kollege scheint unter dem NIH-Syndrom zu leiden ("Not Invented Here").

Es ist durchaus plausibel, dass sein Code das Hinzufügen neuer Felder erleichtert: Ich aktualisiere meinen eigenen Code auch viel schneller als den Code, den andere Leute geschrieben haben. Diese kurzfristige Geschwindigkeit sagt jedoch nichts über die Wartbarkeit und Portabilität des Codes aus. Ich gebe ihm den Vorteil des Zweifels: Der vorhandene Code könnte in der Tat schlecht strukturiert sein, wenn er einem Lehrbuch schlecht gefolgt ist oder einem guten Rezept im falschen Kontext gefolgt ist.

Das Vermeiden von Designmustern ist wirklich überraschend. In den letzten 30 Jahren, in denen ich Codierer codiert und verwaltet habe, haben Designmuster dazu beigetragen, Dinge, die instinktiv erledigt wurden, mit Worten zu versehen und so die Absicht, die Vorteile, die Unannehmlichkeiten, das Risiko, die Chancen und die damit verbundenen Muster schneller zu verstehen. Design Patterns haben sich als echte Beschleuniger zur Beherrschung der Komplexität erwiesen!

• Vielleicht ist Ihr Kollege wirklich viel intelligenter als die meisten von uns und kann es sich leisten, Muster neu zu erfinden, ohne dass die Produktivität spürbar abnimmt?

• Die Argumente, dass "Programmierer Designmuster nicht verstehen", klingen wie "Ich kann nicht wirklich erklären, was ich tue". Oder "Ich möchte nicht über mein eigenes Design streiten". Ich denke wirklich, dass die Strukturierung das allgemeine Verständnis fördern und es weniger erfahrenen Kollegen ermöglichen könnte, wertvolle Meinungen auszutauschen. Aber vielleicht möchte Ihr älterer Kollege genau das vermeiden.

In den meisten Unternehmensanwendungen haben sich mehrschichtige Ansätze gegenüber anderen Architekturen als überlegen erwiesen. Führende Pakete von Weltklasse sind nach dieser Idee strukturiert und übertreffen handwerkliche Architekturen um Größenordnungen.Martin Fowler stellt diesen Ansatz in seinem hervorragenden Buch "Patterns of Enterprise Architecture" vor. Oh! Entschuldigung nochmal: Es geht um bewährte Muster; aus Sicht Ihres Kollegen keine Chance ;-)

Eine wichtige Erkenntnis, die viele Menschen vermissen, ist, dass Software-Design kontextbezogen ist. Es ist vorhanden, um Geschäftsziele zu erreichen, und unterschiedliche Ziele erfordern möglicherweise unterschiedliche Ansätze. Anders ausgedrückt, es gibt kein Design, das immer am besten ist, obwohl es immer ein bestes Design gibt.

Entwurfsmuster sind Standardlösungen für Standardprobleme. Wenn Sie das Problem jedoch nicht haben, ist die Lösung eine Verschwendung von Aufwand.

Der Hauptunterschied zwischen Wasserfall und agilem Softwaredesign ist wann Designentscheidungen getroffen werden. In waterfall erfassen wir alle Anforderungen, identifizieren die benötigten Entwurfsmuster und beginnen erst dann mit der Codierung. In der agilen Architektur folgen wir dem YAGNI-Prinzip, um Entwurfsentscheidungen bis zum letzten verantwortlichen Moment aufzuschieben, wenn wir so viel über die Auswahl wissen, wie wir nur können.

Das heißt, im Wasserfall werden Entwurfsmuster eher angewendet, wenn ihr Bedarf antizipiert wird , und zwar agil, wenn sie tatsächlich benötigt werden . Infolgedessen wenden agile Projekte in der Regel seltener Entwurfsmuster an, da nicht alle erwarteten Bedürfnisse tatsächlich vorliegen.

Entwurfsmuster werden nicht wirklich als Entwurfsmuster bezeichnet, da sie vorschreiben, was zu tun ist. Entwurfsmuster sind Entwurfsmuster, weil sie beschreiben, was zuvor getan wurde . Einige Entwickler haben eine Methode entwickelt, die eine bestimmte Aufgabe gut erfüllt, und konnten sie auf ähnliche Situationen mit ähnlichen Ergebnissen anwenden. Das ist alles was es ist. Viele Muster haben inhärente Stärken und Schwächen, und es liegt an dem ausgebildeten Entwickler, die technologischen und geschäftlichen Anforderungen zu bewerten, um ein geeignetes Muster für die Anwendung zu bestimmen.

Vor diesem Hintergrund verwenden Sie mit ziemlicher Sicherheit zumindest einige Entwurfsmuster, es sei denn, Sie möchten wirklich 100% igen Einmalcode schreiben, bei dem von Anwendungsfall zu Anwendungsfall keine Konzepte oder Implementierungen verwendbar sind. Sie haben vielleicht keine auffälligen, gebräuchlichen Namen wie "Repository" oder "Unit of Work" oder sogar "MVC", aber das macht sie nicht "kein Designmuster".

Normalerweise denke ich gerne daran, wie man mit dem GPS "navigiert". Beim Erlernen von "Best Practices" und "Entwurfsmustern" lernen Sie, die GPS-Navigationsroute zu verwenden. Aber wenn Sie die Gegend kennen, werden Sie oft feststellen, dass das Befahren einer Nebenstraße Sie an Problemzonen vorbeiführt und Sie schneller und / oder besser dorthin bringt. Ähnlich ist es mit diesen Dingen: Durch Erfahrung können Sie Ihre Werkzeugkiste dekonstruieren und Verknüpfungen vornehmen.

Das Erlernen von Entwurfsmustern und das Erlernen von "Best Practices" bedeutet, dass Sie sich ein Bild über die dahinter stehende Idee machen und in einer bestimmten Situation eine Entscheidung treffen können. Da reale Situationen im Vergleich zu theoretischen Situationen häufig komplexer sind, gibt es häufig Einschränkungen und Probleme, die in den Lehrbüchern nicht enthalten sind. Kunden / Kunden wollen ihr Produkt schnell und in der Regel günstig; Sie müssen mit altem Code arbeiten. Sie müssen mit Tools von Drittanbietern interagieren, die sehr wahrscheinlich Black Boxes und ineffektiv sind. und alle möglichen Dinge. Ihre Situation ist spezifisch - Best Practices und Muster sind allgemeiner.

Ein Hauptgrund dafür, dass viele Leute auf Websites wie SE Ihnen Antworten auf bewährte Verfahren und Entwurfsmuster geben, ist, dass sie in einer allgemeinen und abstrakten Lösung antworten und dadurch eine gemeinsame Sprache für die Lösung einer Art von Problemen bereitstellen Probleme. Und dich zum Lernen zu bringen.

So werden Designmuster in agilen Entwicklungsumgebungen nicht verpönt. Die Entwicklung ist jedoch selten allgemein und abstrakt genug, um perfekt zu einem Muster zu passen, und der (erfahrene) Entwickler weiß dies.

Das Hinzufügen eines neuen Felds zur Benutzeroberfläche / Datenbank / Datenebene dauert 2-3 Stunden, wobei es wie in seinem Code 30 Minuten dauert.

Wenn Sie ein Design "optimieren" möchten, müssen Sie angeben, was Sie optimieren möchten.

Ein Rennrad ist zum Beispiel ein optimiertes Fahrzeug ... und eine Boeing 747 ist auch ein optimiertes Fahrzeug ... aber sie sind für unterschiedliche Anforderungen optimiert.

Die Idee des "MVC" Musters optimiert zum Beispiel für Dinge wie:

• Verschiedene Ansichten desselben Modells (Ansicht ist modellunabhängig)
• Jede Schicht kann separat entwickelt (z. B. von verschiedenen Teams) und vor der Integration separat getestet (Komponententests) werden
• usw.

Während sein Code für etwas anderes optimiert sein könnte, zum Beispiel:

• Minimale Codezeilen
• Es ist für eine Person einfach, Änderungen vorzunehmen, die sich auf alle Ebenen auswirken (da keine wirklich unterschiedlichen Ebenen vorhanden sind).
• usw.

Musterbeschreibungen beginnen mit einer Beschreibung des Problems, das mit dem Muster gelöst werden soll. Wenn er meint, es sei "Best Practice", kein bestimmtes Muster zu verwenden, dann (vorausgesetzt, es ist kein dummes Muster, vorausgesetzt, es ist manchmal ein nützliches Muster), nehme ich an, dass er das spezifische Problem, das dieses Muster behauptet, nicht hat / erlebt zu lösen, und / oder er hat ein anderes (größeres oder dringenderes, konkurrierendes) Problem, für das er stattdessen zu optimieren versucht.

Entwurfsmuster sind Werkzeuge. Wie bei Werkzeugen gibt es zwei Möglichkeiten, sie zu verwenden: die richtige und die falsche. Wenn ich Ihnen zum Beispiel einen Schraubenzieher und einen Nagel gebe und Sie bitten, zwei Holzstücke zusammenzufügen, sollten Sie mich um einen Hammer bitten. Hämmer werden für Nägel verwendet, während Schraubendreher für Schrauben verwendet werden.

Zu oft wird ein Entwurfsmuster als One True Way beworben, was häufig nur dann zutrifft, wenn bestimmte Probleme auftreten. Nachwuchsentwickler sind oft wie Kinder, wenn sie etwas Neues zum Spielen finden. sie wollen dieses Designmuster auf alles anwenden . Und es ist von Natur aus nichts falsch daran, solange sie irgendwann erfahren, dass Muster A für Problem B gilt und Muster C für Problem D. So wie Sie keinen Schraubendreher zum Eintreiben von Nägeln verwenden, verwenden Sie auch keinen bestimmten Muster, nur weil es existiert; Sie verwenden das Muster, weil es das beste (bekannte) Werkzeug für den Job ist.

Die Kehrseite von Mustern sind Anti-Muster. Dinge, die sich immer wieder als schlecht erwiesen haben, normalerweise in Bezug auf Ausführungszeit oder Speicher. Sowohl Muster als auch Anti-Muster nützen dem Entwickler jedoch nichts, der nicht versteht, warum sie existieren. Entwickler denken gerne, dass das, was sie tun, neu und erfinderisch ist, aber meistens sind sie es nicht. Es ist wahrscheinlich schon früher gedacht worden. Menschen vor ihnen haben die Muster aufgrund von Erfahrung erstellt.

Natürlich scheinen Junior-Entwickler oft neue Wege zu finden, um alte Dinge zu tun, und manchmal sind diese Wege besser. Es kommt jedoch zu oft vor, dass es sich um den Mahn-Krüger-Effekt handelt. Der Entwickler weiß gerade genug, um ein funktionierendes Programm zu erstellen, versteht jedoch nicht die eigenen Einschränkungen. Der einzige Weg, dies zu überwinden, scheint durch positive und negative Erfahrungen zu sein. Sie ignorieren Muster, weil sie sich für überlegen halten, wissen aber nicht, dass in Wirklichkeit 10.000 Entwickler bereits ein bestimmtes Design verwendet und es dann verworfen haben, weil es tatsächlich schlecht war.

Agile befürwortet die "reaktionsschnelle Erledigung", um sich schnell an sich verändernde Kundenbedürfnisse anzupassen. Designmuster werden weder bevorzugt noch verachtet. Wenn ein Muster die schnellste und zuverlässigste Methode ist, sollte der Entwickler es verwenden. Wenn ein bestimmtes Muster mehr Zeit kosten würde als nur "erledigt", ist die Verwendung von etwas, das kein Muster ist, wahrscheinlich in Ordnung (vorausgesetzt natürlich, dass die Leistung nicht erheblich beeinträchtigt wird usw.). Wenn kein bekanntes Muster gefunden werden kann, ist es vorzuziehen, ein eigenes Muster zu entwerfen, anstatt einem Kunden "Nein" zu sagen. Kunden, insbesondere zahlende Kunden, haben normalerweise Recht.

Wer behauptet, dass Muster der Weg sind oder dass Muster der Fluch der Existenz sind, der irrt. Muster sind Werkzeuge, die auf bestimmte Situationen angewendet werden sollen und je nach den Umständen unterschiedlich erfolgreich sind. Dies ist eine Wahrheit, die nicht davon abhängt, ob Sie MVC gewählt haben oder nicht, ob Sie Datenübertragungsobjekte verwenden oder nicht usw. Worauf es ankommt, ist die Implementierung von Code in einem angemessen kurzen Zeitrahmen, der für Benutzer eine angemessene Leistung erbringt. und ist einigermaßen frei von Logikfehlern.

In der Regel ermöglichen Muster eine kohärente Form des Designs und erzielen eine bessere Leistung, als alle Muster zu ignorieren, um 100% originelle Ideen zu schreiben. Sie können jedoch nicht alle Muster vermeiden. Wenn zum Beispiel y = x + 5 ist, schreiben Sie dann wirklich y = x + (5 * 3 + 15/3) / 4, um das Muster des Schreibens von x + 5 zu vermeiden? Nein, du bist nicht. Sie schreiben y = x + 5 und fahren mit dem nächsten Problem fort.

Die Leute benutzen jeden Tag Muster, und das ist in Ordnung . Am wichtigsten ist, dass der Code logisch funktioniert, selten abstürzt und benutzerfreundlich ist. Nichts anderes ist wichtiger als das.

Sie können Entwurfsmuster nicht vermeiden, es sei denn, Sie vermeiden es, zwei Teile Ihres Systems auf dieselbe Weise zu entwerfen (was ich nicht empfehle und ich bezweifle, dass Ihr leitender Entwickler dies tut). Was er wahrscheinlich meint, ist, "ein Design nicht blind zu verwenden, nur weil es einem Designmuster entspricht". Darüber nachzudenken , was Sie tun , ist auf jeden Fall ein ‚best practice‘, und eine Universitäten sollten zu lehren existieren; Leider scheint das nicht zu passieren.

Entwurfsmuster stehen agilen Praktiken nicht entgegen. Was im Gegensatz zu agilen Praktiken steht, ist die Verwendung von Entwurfsmustern, um Entwurfsmuster zu verwenden. Dies ist eine gängige Praxis für junge Absolventen und Studenten, um zu überlegen, wie wir dieses Problem mithilfe eines Fabrikmusters lösen können.

Agil bedeutet, das beste Werkzeug für den Job auszuwählen und NICHT zu versuchen, den Job so zu formen, dass er zum ausgewählten Werkzeug passt.
Und genau darauf kommt es bei ALLEN gängigen Entwicklungspraktiken an (obwohl Sie natürlich häufig Kompromisse eingehen müssen, da die Auswahl der Tools in der Regel durch Unternehmensstandards, Lizenzbeschränkungen (wie GPL und manchmal andere Open-Source-Tools) eingeschränkt ist kann nicht verwendet werden, insbesondere wenn Software für den Wiederverkauf erstellt wird.

Ihr Kollege / Freund hat wahrscheinlich Einwände gegen Ihren Code erhoben, nicht weil er Designmuster per se verwendet, sondern weil es sich um ein künstliches Konstrukt handelt, das die Verwendung eines bestimmten Musters zeigt, wenn ein anderes Design besser gewesen wäre (obwohl oft subjektiv, habe ich (und Viele von mir haben zweifellos viele Beispiele gesehen, bei denen die erzwungene Verwendung eines bestimmten Entwurfsmusters zu hässlichem, schwer zu wartendem und höchst ineffizientem Code führte.