Wie weit gehen Sie mit YAGNI?

Question

Ich entwickle eine neue, revolutionäre Webanwendung für den Unternehmensmarkt. Sicher, viele vor mir dachten, dass ihre Webanwendung revolutionär sein würde, nur um herauszufinden, dass sie es nicht ist. (Oder sie ist es, aber das Geschäft läuft trotzdem nicht gut).

Um herauszufinden, ob meine Idee mit den geringsten Kosten durchsetzbar ist, überlege ich, ein extremes YAGNI zu verfolgen:

• Keine Sicherheitsmerkmale (d. h. keine Benutzer usw.). Für jeden neuen Kunden installiere ich eine neue Datenbankinstanz und eine neue Webapp-Instanz. Jede Webapp-Instanz ist durch ein http-Server-Passwort geschützt (Digest oder Basisautorisierung, vielleicht über https).

• Keine Internationalisierung. Nur englische Zeichenfolge in den Quellcode eingebettet.

• Keine Entkopplung. Nur Webseiten, die mit der Datenbank kommunizieren.

• Keine Leistungstricks. Keine Warteschlangen, Caches, Timer, Hintergrundaufträge, asynchrone Aufrufe usw.

• Keine Skalierbarkeit. Keine Datenbankpartitionierung, keine Shards, kein Clustering oder Replikation.

• Verwenden Sie außerdem YAGNI auf der Mikroebene, wann immer es sich anbietet.

Ich möchte einfach nur mit dem Projekt beginnen und so schnell wie möglich einen Punkt erreichen, an dem ich meine innovativen Funktionen mit einer einfachen und ansprechenden Benutzeroberfläche verkaufen (oder zu verkaufen versuchen) kann.

Wenn der Plan scheitert, werde ich es frühzeitig erfahren. Wenn er erfolgreich ist, werde ich sehen, was die Kunden dann wollen. Wollen sie eine französische Version? Oder wollen sie Benutzer und Rollen innerhalb der Organisation?

Ist es das, was die Menschen mit YAGNI meinen, oder ist dies ein pathologisches und übertriebenes Beispiel für YAGNI?

Answer 1

Ich stimme mit dem YAGNI-Prinzip voll und ganz überein, aber man muss trotzdem den Erfolg planen. Wenn eine Anwendung komplett neu geschrieben werden muss, wenn sie plötzlich mehr als zehn Benutzer hat, dann ist das YAGNI zu weit gegangen.

Einige Dinge, die Sie brauchen werden. Aus meiner Sicht sind die beiden wichtigsten Punkte:

• Schießen Sie sich nicht selbst in den Fuß, indem Sie Ihre Anwendung nicht auf die Internationalisierung vorbereiten. Wenn Ihre Anwendung etwas taugt, wird die Internationalisierung eines Tages auf den Tisch kommen. Außerdem ist die Fähigkeit, fremde Zeichen mit UTF-8 zu verarbeiten, eine absolute Voraussetzung, wenn Sie eine Anwendung im Jahr 2010 von Grund auf neu erstellen. Für einen englischen Muttersprachler mag die Internationalisierung nicht so wichtig erscheinen, aber glauben Sie mir, sie ist essentiell und der Schmerz, eine Anwendung später zu internationalisieren, ist schrecklich.

• Überlegen Sie sich das mit den fehlenden Sicherheitsmerkmalen gut. Was ist mit einer Organisation oder Gruppe, die mit Ihrer App arbeiten möchte, mit Benutzern auf verschiedenen Sicherheitsstufen. Es pourrait Ich habe ein feinkörniges Sicherheitssystem in viele meiner Produkte eingebaut, das bisher noch nicht voll ausgeschöpft worden ist. Aber denken Sie gut darüber nach, ob Ihre spezifische Anwendung darauf verzichten kann, selbst wenn sie erfolgreich ist.

Answer 2

Dies nennt man "Prototyping". Probieren Sie es aus.

Zwischen YAGNI und dem Prototyping gibt es einen feinen Unterschied.

1. Wenn es sich um eine vom Benutzer gewünschte Funktion handelt und Sie nein sagen, dann ist das YAGNI.

2. Wenn es um die Implementierung geht (I18N, "Entkopplung"(?), Warteschlangen, Caches, Timer, usw.) und Sie sich selbst ablehnen. Das ist nicht wirklich YAGNI. Das ist Prototyping.

Das meiste von dem, was Sie hier haben, scheint kein nutzerorientiertes Goldplating zu sein. Ich würde das - genau genommen - nicht YAGNI nennen.

Answer 3

Bei YAGNI geht es darum, Sie daran zu erinnern, den Unterschied zwischen dem zu sehen, was Sie kann tun und was Sie tun müssen, um Ihre Anforderungen zu erfüllen.

Wenn Ihre Anforderung zum Beispiel lautet: "Benutzer können Konten erstellen und sich anmelden", verwenden Sie einfach die Standard-Authentifizierungsmethoden Ihres Frameworks und fahren Sie mit der nächsten Anforderung fort.

Ihre Webanwendung kann unterstützen OpenID, Active Directory, lokale Datenbank, Flat File und zig andere Arten von Authentifizierungsmethoden, aber Sie können die Anforderung erfüllen, indem Sie die einfachste Methode implementieren. (Für mich, YAGNI impliziert DTSTTCPW ).

"Ich kann alles tun, wenn ich genug Zeit habe"

- Jeder Programmierer, den ich je getroffen habe

Answer 4

Ich selbst bin kein Fan des YAGNI-Prinzips; ich sehe, dass es viel zu oft zur Rechtfertigung von schlecht konzipierter Software verwendet wird. Überentwickelte Software ist natürlich auch ein Problem, aber "YAGNI" lässt nicht wirklich viel Raum für eine tatsächliche Folgenanalyse.

Es stellt sich heraus, dass in der Welt der Software viele Dinge, von denen man denkt, dass man sie nicht braucht, tatsächlich benötigt werden. Und dann noch einiges mehr. Wer hätte das gedacht.

Ich habe ein oder zwei Anwendungen geschrieben, die eigentlich Wegwerfanwendungen oder Überbleibsel sein sollten, die nach zwei Jahren immer noch in Produktion sind. Es ist mühsam, sie zu pflegen.

Vor allem, wenn es um etwas wie Sicherheit geht - Sie haben wahrscheinlich sind Sie werden es brauchen.

Answer 5

Wenn Sie "YAGNI" bis zum Äußersten treiben (und ich werde die Diskussion darüber, ob das eine gute Idee ist oder nicht, ebenso umgehen wie die Diskussion darüber, ob das wirklich "YAGNI" ist oder nicht), sollten Sie darauf vorbereitet sein, Ihre Codebasis gnadenlos zu überarbeiten, um später das hinzuzufügen, was Sie jetzt weglassen, ohne einen Ball of Mud zu erzeugen.