Wie einfach ist eine echte KISS-Lösung? [geschlossen]

Ich gebe zu : Ich habe ein Problem damit, es die meiste Zeit einfach und kurz zu halten, weil der Versuch, es gemäß den Büchern, die ich gelesen habe, den Designmustern, die ich gehört habe usw. zu machen, mir eine solche Begeisterung gibt - eine Begeisterung, von der ich komme In diesem Sinne bin ich auf dem richtigen Weg zu einer wahrscheinlichen Vollkommenheit.

Auf der anderen Seite, ja, es stellt eine zusätzliche Belastung für mich dar, wenn ich manchmal die Fristen einhalten muss ...

Aber wenn ich zu mir selbst sage: "Mach es das nächste Mal einfach, du Dummkopf!" Ich finde es ziemlich schwierig, es "einfach" zu machen, wenn das nächste Mal kommt, weil es sich nach einem Punkt komisch anfühlt ... und unangenehm.

Dann beginne ich mein Verständnis von 'einfach' zu beurteilen ...

Bedeutet SIMPLE zu kurz, dass es funktioniert, aber schwer zu warten und zu erweitern?

Bedeutet SIMPLE, viele der OOP-Prinzipien zu brechen?

Bedeutet SIMPLE Schummeln?

Bedeutet SIMPLE, nur die Fristen einzuhalten, ohne taub zu sein? etc.

Was ist das eigentlich?

Die Frage ist : Können Sie die EXAKTE Definition von SIMPLE im Sinne des KISS-Prinzips schreiben? -Wenn da ist.

Vielen Dank!

Lass uns einen französischen KUSS lernen:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. - Antoine de Saint-Exupéry

Welches ist übersetzt zu:

Perfektion wird erreicht, nicht wenn nichts mehr hinzuzufügen ist, sondern wenn nichts mehr wegzunehmen ist. - Antoine de Saint-Exupéry

Szenario

Sie müssen schneiden und kneifen.

Lösung A: Nicht KISS

Lösung B: KISS

Zur genauen Definition: Es ist schwierig, eine absolute Skala für die Messung der Einfachheit zu definieren. Meistens, weil wahre Einfachheit ein echtes Verständnis des vorliegenden Problems ausschließt, und das ist selten erreichbar. Angenommen, Lösung A und B veranschaulichen den Unterschied zwischen Lösungen, die zu Überkomplizierung bzw. Einfachheit neigen.

"Mach die Dinge so einfach wie möglich, aber nicht einfacher" -Einstein

Code so einfach wie möglich zu halten, aber nicht einfacher, hängt vom zu lösenden Problem ab. So lange sich das zu lösende Problem ändert, ändert sich auch KISS.

Es gibt ein Gleichgewicht zwischen Über-Engineering (oh man, das scheint ein großartiger Ort zu sein, um meine Design-Pattern-Fähigkeiten zu demonstrieren!) Und Unter-Engineering (wenn ich nur eine Fabrik hätte, hätte ich diese Kupplung nicht, die mich dazu brachte, 20 zu machen) Codeänderungen ...). Das Ziel ist Wartbarkeit.

Einfach heißt nicht, gute Programmierprinzipien zu brechen. In der Tat bedeutet es eher das Gegenteil.

Bedeutet SIMPLE zu kurz, dass es funktioniert, aber schwer zu warten und zu erweitern?

Schwierig zu warten und zu erweitern sind ein großes Symptom für Komplexität. Tatsächlich finde ich, dass das Erweitern von Code zu einfacherem Code führt, da Sie nicht mit jedem einzelnen Fall anfangen, können Sie den Basiscode einfacher halten.

Bedeutet SIMPLE, viele der OOP-Prinzipien zu brechen?

Nein. Die meisten OOP-Prinzipien zielen darauf ab, den Code sauberer und organisierter zu halten, was letztendlich einfacher ist.

Bedeutet SIMPLE Schummeln?

Nein, schwer zu pflegender Code und Hacks unter dem Deckmantel der Einhaltung von Fristen sind.

Bedeutet SIMPLE, nur die Fristen einzuhalten, ohne taub zu sein? etc.

Nein. Fristen und die Einfachheit Ihres Codes sind zwei getrennte Punkte. Das Schreiben von einfachem Code dauert nicht länger (obwohl es ein weit verbreitetes Missverständnis ist).

Dies zu erklären ist sehr schwierig, da Einfachheit nicht für alle dasselbe bedeutet.

Beispiel. Einige Entwickler halten das ?:für einfach, andere für ifbesser. Wenn es so weit ist, kann man nicht allen gefallen.

Im Allgemeinen bedeutet einfach ohne Komplexität . Um die Einfachheit zu verstehen, müssen wir die Komplexität verstehen.

Es gibt zwei Arten von Komplexität:

Wesentliche Komplexität bezieht sich auf eine Situation, in der alle vernünftigen Lösungen für ein Problem kompliziert (und möglicherweise verwirrend) sein müssen, da die "einfachen" Lösungen das Problem nicht angemessen lösen würden. - Wikipedia

Zufällige Komplexität ist Komplexität, die in Computerprogrammen oder deren Entwicklungsprozessen (Computerprogrammierung) auftritt und für das zu lösende Problem nicht wesentlich ist. - Wikipedia

Sie können die wesentliche Komplexität mit den folgenden Fragen überprüfen:

Ist diese Lösung einfach? Kann ich es meinem Kollegen in ein paar Minuten erklären und sie bekommen es? Gibt es eine einfachere Lösung für das Problem? Wenn ja, gibt es Kompromisse zwischen der komplizierten und der einfachen Lösung? Können wir mit diesen Kompromissen leben? Beispielsweise machen viele Programmierer einen Fehler bei der Mikrooptimierung, und ihre Lösung (und auch der Code) wird zu kompliziert.

Überprüfen Sie Ihre zufällige Komplexität:

Ist der Code einfach? Wenn ich in drei Monaten darauf zurückkomme, wie lange werde ich brauchen, um den Kontext in meinem Gehirn aufzubauen, damit ich die notwendigen Änderungen vornehmen kann? Hat alles in meinem Quellcode einen klaren Zweck und vermittelt er mir und anderen Entwicklern diesen Zweck effektiv ? Wie schwer ist es, meinen Code zu testen? Je komplizierter Ihr Code ist, desto schwieriger ist es normalerweise, einen Komponententest durchzuführen. Daher verwende ich diesen Code normalerweise als Maß für die Komplexität. Normalerweise möchten Sie kleine, gut benannte und fokussierte Klassen und Methoden. Entwurfsmuster helfen Ihnen in der Regel auch dabei.

Wenn Sie ein Entwurfsmuster verwenden möchten, nur weil Sie es gerade gelesen haben, führt dies wahrscheinlich zu einer ungewollten Komplexität. Wenn Sie etwas einbauen möchten, weil Sie denken, dass es „intelligent“ ist, führt dies wahrscheinlich zu einer zufälligen Komplexität.

Ich hoffe das hilft und vergiss nicht: Einfach heißt nicht EINFACH .

Ich hatte immer das Gefühl, dass die Prinzipien hinter X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) es wert waren, beachtet zu werden. Dieses Ziel gelingt mir nicht immer.

Insbesondere muss ich mich immer wieder daran erinnern ... "Fügen Sie keine neuen Funktionen hinzu, es sei denn, Sie kennen eine echte Anwendung, die dies erfordert." Und "Wenn Sie 90 Prozent des gewünschten Effekts für 10 Prozent der Arbeit erzielen können, benutze die einfachere Lösung. "

Die Frage ist: Können Sie die EXAKTE Definition von SIMPLE im Sinne des KISS-Prinzips schreiben? -Wenn da ist.

Nein.

Einfach - in diesem speziellen Kontext ist das genaue Gegenteil zu komplex. Einfach muss nicht heißen: Jeder Dummkopf muss es verstehen - aber man muss sicherstellen, dass man es verstehen kann, auch wenn man es nicht selbst geschrieben hat.

Komplexität könnte erreicht werden, wenn man die Referenzen nur schwer versteht - werdet sie los! Viele Dateien / Klassen miteinander verknüpft - auf keinen Fall! Und komplizierter Code (das heißt: verkettete Schleifen, mehrere ITE-Ebenen usw.) - das will niemand lesen.

Meiner Meinung nach ist es sehr einfach, eine weitere Funktion hinzuzufügen. In Klassen können Sie auch private Funktionen hinzufügen, damit Sie sich nicht mit der Schnittstelle anlegen. Nutzen Sie diesen Vorteil und beschränken Sie Ihre Funktionen / Prozeduren auf 50 Zeilen. Vielleicht noch weniger. Holen Sie sich einige aussagekräftige Namen. Auf diese Weise machen Sie die meisten Kommentare überflüssig. Auf diese Weise sind Ihre Funktionen leicht zu lesen, leicht zu ändern / zu erweitern.

Natürlich ... die letzten paar Sätze hätten so gewirkt: In Klassen gibt es die Möglichkeit, private Funktionen zu definieren. Nutzen Sie einfach diese Möglichkeit, um Funktionen in 50 Zeilen aufzuteilen, damit sie besser lesbar sind (vergessen Sie keine guten Namen, Sie brauchen also nicht so viel zu kommentieren).

ABER: Es ist viel einfacher (!), Alles zu lesen, wenn es einen Punkt gibt, der zeigt: Ich habe einen Gedanken beendet, lass uns mit dem nächsten fortfahren.

Das würde ich als einfach bezeichnen.