Design für zukünftige Änderungen oder Lösung des vorliegenden Problems [geschlossen]

Versuchen Sie beim Schreiben des Codes oder beim Entwerfen, das Problem in der ersten Instanz selbst zu verallgemeinern, oder versuchen Sie, dieses sehr spezifische Problem zu lösen.

Ich frage dies, weil der Versuch, das Problem zu verallgemeinern, dazu führt, dass die Dinge kompliziert werden (was möglicherweise nicht notwendig ist), und es andererseits sehr schwierig ist, die spezifische Lösung zu erweitern, wenn sich die Anforderung ändert.

Ich denke, die Lösung ist, den Mittelweg zu finden, der leichter gesagt als getan ist. Wie gehen Sie dieses Problem an? Wenn Sie anfangen, es zu generalisieren, zu welchem ​​Zeitpunkt wissen Sie, dass so viel Generalisierung ausreicht?

Zu oft, wenn Sie versuchen, für die Zukunft zu entwerfen, stellen sich Ihre Vorhersagen über zukünftige Bedürfnisse als falsch heraus. In der Regel ist es besser, eine Umgestaltung vorzunehmen, wenn Sie tatsächlich wissen, wie sich die Anforderungen geändert haben, als Ihr System am ersten Tag zu überarbeiten. Schießen Sie sich dabei auch nicht in den Fuß. Es gibt sicherlich einen Mittelweg, und zu wissen, wo das ist, ist mehr Kunst als Wissenschaft.

Um es auf eine Faustregel zu bringen: Weniger ist mehr.

Kennen Sie sich mit Agile aus? Eines der großen Prinzipien von Agile ist YAGNI . Ich finde, das ist der beste Weg, um Dinge anzugehen.

"Du wirst es nicht brauchen" ... ist ein Prinzip der extremen Programmierung (XP), das besagt, dass ein Programmierer erst dann Funktionalität hinzufügen sollte, wenn dies als notwendig erachtet wird. Ron Jeffries schreibt: "Implementieren Sie Dinge immer, wenn Sie sie tatsächlich brauchen, niemals, wenn Sie nur vorhersehen, dass Sie sie brauchen."

... YAGNI ist ein Prinzip hinter der XP-Praxis, "das Einfachste zu tun, was möglicherweise funktionieren könnte" (DTSTTCPW). Es soll in Kombination mit mehreren anderen Methoden verwendet werden, wie z. B. kontinuierliches Refactoring , kontinuierliches automatisiertes Testen von Einheiten und kontinuierliche Integration . Ohne kontinuierliches Refactoring kann dies zu unordentlichem Code und massiven Nacharbeiten führen. Continuous Refactoring setzt wiederum auf automatisierte Komponententests als Sicherheitsnetz (um unvorhergesehene Fehler zu erkennen) und kontinuierliche Integration, um größere Integrationsprobleme zu vermeiden ...

YAGNI wird auch in Kombination mit den unterstützenden Praktiken nicht allgemein als gültiges Prinzip akzeptiert. Die Notwendigkeit, es mit den unterstützenden Methoden zu kombinieren, anstatt es eigenständig zu verwenden, ist Teil der ursprünglichen Definition von XP ...

Dies ist wahrscheinlich einer der schwierigsten Teile der Softwareentwicklung, da Sie die Grenze zwischen "YAGNI" und "PYIAC" (Paint Yourself Into A Corner) überwinden müssen.

Es ist ziemlich einfach zu sagen, "schreibe keine Funktion, es sei denn, du brauchst sie". Der schwierige Teil besteht darin, Ihren Code so zu gestalten, dass Sie später problemlos Funktionen hinzufügen können, wenn Sie sie benötigen.

Der Schlüssel ist, in der Lage zu sein, eine erweiterbare Architektur zu entwerfen, in der Sie nicht mehr Code schreiben, als Sie derzeit benötigen. Die Fähigkeit, dies gut zu machen, beruht auf einer Menge Erfahrung (und Schmerzen).

Ich verbringe einige Zeit im Voraus damit, über die allgemeine Richtung des Entwurfs nachzudenken - nicht zu viel, aber genug, um im Grunde genommen einen Überblick auf hoher Ebene zu skizzieren. Anschließend verfolge ich eine auf Storys basierende agile Methodik, bei der mithilfe von TDD Lösungen für einzelne Storys entwickelt werden. Wenn ich über TDD implementiere, behalte ich meinen Überblick auf hoher Ebene im Hinterkopf und leite entweder (a) meine bestimmten Implementierungen, um dem Überblick auf hoher Ebene zu folgen, oder (b) baue (und verbessere) mein Verständnis / meine Richtung auf hoher Ebene basierend Was ich beim Testen / Implementieren lerne.

Ich denke, es ist ein Fehler, keine Vorausplanung zu machen, aber es ist wahrscheinlich ein größerer Fehler, zu viel zu tun. Nach Möglichkeit möchte ich mich von meiner Erfahrung leiten lassen und dann das Design organisch wachsen lassen, so wie ich es mir für die Entwicklung der Anwendung vorgestellt habe. Bei der Verwendung von TDD stelle ich fest, dass das Design selbst zu besseren Designprinzipien (entkoppelt, einzelne Verantwortung usw.) gezwungen ist und sich in Bezug auf Änderungen besser formulieren lässt, als wenn ich versuche, das Ganze vorauszudenken und die Entwicklung darauf abzustimmen.

Ein gutes Design nimmt zukünftige Veränderungen auf und ist auf jeden Fall einen Besuch wert. Betrachten Sie das UNIX-Betriebssystem und dessen "Alles ist eine Datei-Philosophie". Diese Entwurfsentscheidung wurde nicht getroffen, um einen unmittelbaren Bedarf zu decken, sondern im Hinblick auf zukünftige Anforderungen. Man schaudert, wenn man sich überlegt, wie ein auf einem "agilen" Design basierendes Betriebssystem aussehen würde.

Was Sie versuchen, damit umzugehen, hat mit der Wiederverwendung zu tun (dh der Verallgemeinerung eines Problems, mit dem Sie sich jetzt befassen, damit Sie die Arbeit (den Code) in Zukunft wiederverwenden können). Ich habe es schon einmal gesagt und ich werde wieder darauf verlinken .

Ich glaube, ich habe andere Leute etwas sagen hören, um Folgendes zu bewirken:

Ich löse das Problem beim ersten Mal. Wenn ich meine Lösung zum ersten Mal wiederhole, merke ich es. Wenn ich es noch einmal wiederhole, überarbeite ich.

Entwurf für "jetzt + 1". Das heißt, lösen Sie das unmittelbare Problem und bauen Sie genügend Funktionen ein, damit Sie, wenn Sie das nächste Mal nach einer Änderung fragen, diese bereits zur Hälfte (oder mehr) erledigt haben und die Wahl haben, entweder a) sie sofort zu lösen und späteres Refactoring oder b) erneutes Lösen von "now + 1" (mit der "now" -Hälfte)

Dies hängt vom jeweiligen Projekt ab. Kurz gesagt, die Erfahrung zeigt Ihnen, was die "+1" sind.

Die Philosophie von YAGNI , Sie werden es nicht brauchen, lässt sich wie folgt zusammenfassen (aus dem Artikel):

Nach Ansicht der Befürworter des YAGNI-Ansatzes hat die Versuchung, Code zu schreiben, der derzeit nicht erforderlich ist, aber möglicherweise in der Zukunft liegt, die folgenden Nachteile:

• Die aufgewendete Zeit wird für das Hinzufügen, Testen oder Verbessern der erforderlichen Funktionen benötigt.
• Die neuen Funktionen müssen getestet, dokumentiert und unterstützt werden.
• Jede neue Funktion unterliegt Einschränkungen für die zukünftige Ausführung, sodass eine unnötige Funktion jetzt möglicherweise die spätere Implementierung einer erforderlichen Funktion verhindert.
• Bis die Funktion tatsächlich benötigt wird, ist es schwierig, ihre Funktion vollständig zu definieren und zu testen. Wenn die neue Funktion nicht richtig definiert und getestet ist, funktioniert sie möglicherweise nicht richtig, auch wenn sie eventuell benötigt wird.
• Das führt dazu, dass der Code aufgebläht wird. Die Software wird größer und komplizierter.
• Wenn es keine Spezifikationen und Revisionskontrollen gibt, ist die Funktion Programmierern möglicherweise nicht bekannt, die davon Gebrauch machen könnten.
• Das Hinzufügen der neuen Funktion kann andere neue Funktionen vorschlagen. Wenn diese neuen Funktionen ebenfalls implementiert werden, kann dies zu einem Schneeballeffekt in Richtung schleichenden Featurismus führen.

Ich bin der festen Überzeugung, für das jeweilige Problem zu entwerfen und Ihr Design nicht auszublasen, indem ich versuche, alle Fälle zu erraten, für die Sie etwas zu tun haben, weil "wir es eines Tages brauchen könnten".

Im Grunde genommen bedeutet dies bei einer Liste spezifischer Anforderungen nicht, dass Sie Folgendes nicht tun sollten:

• Machen Sie Aspekte Ihres Designs konfigurierbar, anstatt diese Aspekte in Ihrer Lösung fest zu codieren. Entweder über zur Laufzeit übergebene Parameter oder über eine externe Konfiguration, die beim Start (oder nach HUP'ing) gelesen wird.
• Geben Sie Ihren Code mit magischen Zahlen ein,
• Vermeiden Sie es, nachzuschauen, ob bereits etwas geschrieben ist, das Sie wiederverwenden können, möglicherweise nachdem Sie die vorhandene Lösung angepasst haben, um einen Ansatz bereitzustellen, der sowohl für die vorhandene Situation als auch für die neue (n) Anforderung (en) geeignet ist.

Das Hauptproblem beim Entwerfen für "mögliche Zukünfte" ist, dass Sie immer nur raten. Möglicherweise fundierte Vermutungen anstellen, aber "wenn es hart auf hart kommt", sind es immer noch nur eine Reihe von Vermutungen.

Auf diese Weise haben Sie auch die realistische Möglichkeit, Ihre Lösung auf den allgemeinen Fall abzustimmen, anstatt das spezifische Problem zu lösen, das durch Ihre bekannten Anforderungen definiert ist.

Was sagt das? "Wenn Sie nur einen Hammer haben, fängt alles an, wie ein Nagel auszusehen."

Ich wünschte, ich hätte ein Pfund für jedes Mal, wenn ich jemanden sagen hören würde: "Aber es ist eine Lösung, die für die allgemeinen Fälle, die wir in Zukunft sehen könnten, anpassungsfähiger ist."