SOLIDE Prinzipien gegen YAGNI

Wann werden die SOLID-Prinzipien zu YAGNI?

Als Programmierer machen wir ständig Kompromisse zwischen Komplexität, Wartbarkeit, Entwicklungszeit und so weiter. Unter anderem sind für mich die SOLID-Prinzipien und YAGNI zwei der klügsten Richtlinien für Entscheidungen. Wenn du es nicht brauchst; Baue es nicht und halte es sauber.

Wenn ich mir zum Beispiel die dimecast-Serie auf SOLID ansehe , sehe ich, dass sie als ziemlich einfaches Programm beginnt und ziemlich komplex endet (ja, Komplexität liegt auch im Auge des Betrachters), aber es macht immer noch Ich frage mich: Wann werden SOLID-Prinzipien zu etwas, das Sie nicht brauchen? Alle soliden Prinzipien sind Arbeitsweisen, die es ermöglichen, Änderungen zu einem späteren Zeitpunkt vorzunehmen. Aber was ist, wenn das zu lösende Problem recht einfach ist und es sich um eine Wegwerfanwendung handelt? Oder gelten die SOLID-Prinzipien immer?

Wie in den Kommentaren gefragt:

• SOLIDE Prinzipien
• YAGNI

Es ist immer schwierig, einen Ansatz basierend auf einem Screencast zu beurteilen, da die für Demos ausgewählten Probleme in der Regel so gering sind, dass das Anwenden von Prinzipien wie SOLID schnell den Eindruck erweckt, dass die Lösung völlig überarbeitet ist.

Ich würde sagen, SOLID-Prinzipien sind fast immer nützlich. Wenn Sie erst einmal mit ihnen vertraut sind, müssen Sie nicht mehr absichtlich darüber nachdenken, sie zu verwenden. Es wird einfach natürlich. Ich habe gesehen, dass viele wegwerfbare einmalige Apps mehr als das sind, also habe ich jetzt Angst zu sagen, dass ich etwas wegwerfen werde, weil du es einfach nie weißt.

Wenn ich eine einfache App für eine bestimmte Aufgabe schreibe, verzichte ich manchmal zugunsten einiger funktionierender Codezeilen auf die Prinzipien großer Namen. Wenn ich finde, dass ich zu dieser App zurückkehre, um weitere Änderungen vorzunehmen, werde ich mir die Zeit nehmen, um sie FEST zu machen (zumindest ein wenig, da eine 100% ige Anwendung der Prinzipien selten machbar ist).

In größeren Apps beginne ich klein und wende bei der Weiterentwicklung des Programms nach Möglichkeit die SOLID-Prinzipien an. Auf diese Weise versuche ich nicht, das Ganze bis zur letzten Enumeration von vornherein zu entwerfen. Für mich ist das der Sweet Spot, an dem YAGNI und SOLID koexistieren.

Denken Sie zuallererst an das Problem. Wenn Sie die Prinzipien von YAGNI oder SOLID blind anwenden, können Sie sich später verletzen. Ich hoffe, dass wir alle verstehen können, dass es keinen "einen" Designansatz gibt, der für alle Probleme geeignet ist. Sie können Beweise dafür sehen, wenn ein Geschäft einen Hut verkauft, der als "Einheitsgröße" beworben wird, aber nicht zu Ihrem Kopf passt. Es ist entweder zu groß oder zu klein.

Stattdessen ist es besser, die Prinzipien und Probleme zu verstehen, mit denen sich SOLID befasst. sowie die Prinzipien und Probleme, die YAGNI anzugehen versucht. Sie werden feststellen, dass sich einer mit der Architektur Ihrer Anwendung befasst und der andere mit dem gesamten Entwicklungsprozess. In einigen Fällen kann es zu Überlappungen kommen, es handelt sich jedoch um deutlich unterschiedliche Probleme.

YAGNI (Sie werden es nicht brauchen) geht es darum, Zeit für Entwickler zu sparen, indem Sie einer Brücke, die nur einen 3 Fuß breiten Bach überspannen soll, Stahl-Stahlbetonfundamente hinzufügen, wenn eine einfachere Holzbrücke gerade noch ausreicht fein. Wenn wir einen kilometerlangen Fluss überspannen und mehrere Sattelzugmaschinen unterstützen müssen, brauchen wir natürlich diese zusätzlichen Fundamentarbeiten. Im Wesentlichen fordert YAGNI Sie auf, das Gesamtbild und das Design für die aktuellen Anforderungen zu betrachten. Es geht um das Problem, etwas zu kompliziert zu machen, da wir eine Reihe potenzieller Bedürfnisse antizipieren, die der Kunde noch nicht identifiziert hat.

SOLID kümmert sich darum, wie wir sicherstellen, dass die Brückenteile richtig zusammenpassen und im Laufe der Zeit gewartet werden können. Sie können die SOLID-Prinzipien sowohl auf die Holzbrücke als auch auf die Stahlbetonbrücke anwenden.

Kurz gesagt, diese beiden Konzepte stehen nicht notwendigerweise in Konflikt miteinander. Wenn Sie auf eine Situation stoßen, in der Sie glauben, dass dies der Fall ist, ist es Zeit, einen Blick auf das Gesamtbild zu werfen. Abhängig von Ihrer Schlussfolgerung können Sie sich dafür entscheiden, einen Teil der SOLID-Prinzipien abzuschaffen, oder Sie entscheiden, dass Sie sie wirklich brauchen.

SOLID-Prinzipien werden nicht benötigt, wenn es sich um eine wegwerfbare Anwendung handelt. sonst werden sie immer gebraucht.

SOLID und YAGNI sind nicht uneins: Gutes Design erleichtert die Wartung der Anwendung. YAGNI gibt nur an, dass Sie Ihrer Anwendung nicht die Fähigkeit hinzufügen sollten, diese konfigurierbare Monstrosität zu sein, die alles unter der Sonne kann - es sei denn, sie benötigt sie tatsächlich.

Dies ist der Unterschied zwischen einer Fahrzeugklasse mit genau definierten Grenzen (SOLID) und einer Fahrzeugklasse mit der Fähigkeit zur Selbstheilung (YAGNI), bevor der Kunde danach fragt.

Nichts gilt immer! Lassen Sie sich nicht von Architektur-Astronauten erschrecken! Das Wichtigste ist, zu verstehen, welche Probleme mit diesen Grundsätzen angegangen werden sollen, damit Sie eine fundierte Entscheidung über deren Anwendung treffen können.

Vor kurzem habe ich versucht zu verstehen, wann ich das Prinzip der Einzelverantwortung anwenden sollte ( hier ist, was mir eingefallen ist.)

Hoffe das hilft!

Es gibt ein Zitat, das Einstein zugeschrieben wird (wahrscheinlich eine Variation eines echten ):

"Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher."

Und das ist mehr oder weniger der Ansatz, den ich vor dem Hintergrund des Kompromisses zwischen SOLID und YAGNI verfolge: Wenden Sie sie alternativ an, da Sie nie wissen, ob es sich bei einem Programm um einen Wegwerfcode handelt oder nicht. Fügen Sie also einfach eine Schicht Schmutz hinzu, die funktioniert, und polieren Sie sie dann zu einer saubereren Oberfläche. Hoffnungsvoll.

Es gibt viele Möglichkeiten, ein Programm für ein bestimmtes Problem zu entwerfen. SOLID ist ein Versuch, die Eigenschaften eines guten Designs zu identifizieren. Die ordnungsgemäße Verwendung von SOLID soll zu einem Programm führen, das einfacher zu verstehen und zu ändern ist.

YAGNI und KISS befassen sich mit dem Funktionsumfang. Ein Programm, das mehr Arten von Problemen löst, ist komplexer und abstrakter. Wenn Sie diese Allgemeingültigkeit nicht benötigen, haben Sie Zeit und Mühe aufgewendet, um Code zu erstellen, der schwerer zu verstehen und zu warten ist, aber keinen Mehrwert bietet.

Ein gut gestaltetes Programm konzentriert sich nicht unbedingt nur auf die Funktionen, die es benötigt. Ein Programm, das sich nur auf die Funktionen konzentriert, die es benötigt, ist nicht unbedingt gut gestaltet. Es gibt keinen Kompromiss, nur zwei orthogonale Achsen im Entscheidungsraum. Ein ideales Programm ist modular aufgebaut und hat nur wesentliche Merkmale.

Ich denke, Sie sollten YAGNI starten und SOLIDify, wenn es nötig ist.

Was ich meine ist SOLID ist da, wenn Sie eine neue Klasse hinzufügen, müssen Sie nicht umgestalten, einfach eine Implementierung wechseln (zum Beispiel), meiner Meinung nach, schreiben Sie Ihren Code einfach und wenn Sie sehen, dass Sie sich ändern Sachen - ändere sie mit SOLID (dh die befürchtete Umgestaltung des SOLID soll dich davor bewahren - es ist nicht so schlimm, wenn du gerade erst anfängst).

Sie verschwenden keine Zeit, weil Sie die Arbeit sowieso erledigen müssten (am Anfang) und wo immer es nötig ist, ist Ihr Code nett und aufgeräumt.

Ich schätze, Sie könnten es eine faule Bewertung von SOLID nennen.