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 würde sagen, wenn man zu Beginn allen gesunden Menschenverstand über Bord wirft und das ganze Projekt auf die schnellstmögliche Art und Weise durchführt, dann wird man am Ende einen großen Haufen Schrott haben... Was keineswegs revolutionär(tm) ist.

Wenn Sie wirklich wissen wollen, ob es nützlich sein wird, machen Sie einige Bildschirm-Mock-ups. Vielleicht sogar nur normales, hart kodiertes HTML. Bringen Sie diese zu potenziellen Kunden und sehen Sie, ob Sie einen Fuß in die Tür bekommen können. Wenn einige von ihnen anbeißen, dann reißen Sie sich den Arsch auf und bauen es.

Es wird einige Zeit in Anspruch nehmen, bis ein Vertrag zustande kommt, die Zahlung erfolgt und jemand aus dem Personal Ihres Kunden tatsächlich mit der Nutzung beginnt. Währenddessen bauen Sie es auf.

Höchstwahrscheinlich werden potenzielle Kunden Ihre App sehen und Ihnen hoffentlich sagen, warum sie für sie nicht geeignet ist. Ändern Sie die Mock-Ups und gehen Sie zurück. Iterieren Sie so lange, bis Sie ein Front-End-Design für Ihr Produkt haben, für das jemand bereit ist zu zahlen.

Answer 2

Was ich tun würde, ist:

1) Entwerfen Sie es unter Berücksichtigung der richtigen architektonischen Entscheidungen. Internationalisierung und Sicherheit sind in diesem Fall wahrscheinlich ein Muss.

2) Schaffen Sie bei der Entwicklung die Anknüpfungspunkte für diese Grundsätze, die später umgesetzt werden können. Wenn Sie also Zeit und Budget haben, können Sie sie umsetzen, ohne größere Umbauten vornehmen zu müssen.

3) Dann können Sie sich auf die Funktionen konzentrieren, die Ihre Anwendung zum Erfolg führen und die für Ihre potenziellen Kunden wichtiger sind.

Ich denke also, dass ich in diesem Fall eher nach dem KISS-Ansatz vorgehen würde als nach dem "extremen YAGNI-Ansatz", wie Sie vorgeschlagen haben.

Answer 3

Meiner Meinung nach sollte YAGNI standardmäßig befolgt werden, da es folgende Möglichkeiten bietet die Produktivität stark zu steigern .

Es gibt allerdings einige Ausnahmen. Wenn Sie zum Beispiel eine Bibliothek eines Drittanbieters entwickeln, müssen Sie zumindest ein wenig im Voraus denken und einige künftige Bedürfnisse der Benutzer vorhersehen. Das heißt nicht, dass Sie YAGNI komplett aufgeben müssen, aber Sie sollten es nicht so streng befolgen wie bei einer Eigenentwicklung.

Answer 4

Ja, ABER...

Ich neige dazu, vielen Ihrer Überlegungen zuzustimmen sauf die "keine Entkopplung", denn das "it" in YAGNI steht für Funktionalität, nicht für Denkschritte. Die Einführung einiger Abstraktionen (nur die, die für die Entkopplung benötigt werden) wird sich sofort auszahlen, da Fehler nicht gemacht oder schneller gefunden werden und beseitigt werden.

Eine nette (weil denkfreie) Art, diese Abstraktionen einzuführen wäre, wenn Verwenden Sie ein gutes Web-Framework und befolgen Sie einfach die darin vorgeschlagene Anwendung Strukturierungsstil .

Als Nebeneffekt wäre es dann viel einfacher, die Sicherheit zu erhöhen, Internationalisierung, Leistung und Skalierung später hinzuzufügen und Ihr jetziges YAGNI-Verhalten sollte einigermaßen sicher werden.

(Leider gilt das Argument nur, wenn Sie die Web-Framework bereits kennen. Im YAGNI-Reich regiert das Wissen).