Ich finde, dass ich dieses Muster die ganze Zeit durchbrich.
YAGNI - Sie werden es nicht brauchen
Ich bin nur ein Junior-Entwickler, aber ich finde sogar, dass Senior-Entwickler dasselbe tun.
"Nun, dieses System könnte es benutzen, und dieses, also lasst uns dafür entwerfen."
Manchmal fange ich mich selbst, aber meistens renne ich wild herum. Hat jemand irgendwelche Tipps, um sich an YAGNI zu halten, oder was ich tun kann, um dieses Designmuster während des Entwerfens und Codierens besser durchzusetzen?
Entwerfen für etwas
... ist völlig anders als
Etwas entwerfen.
Wenn Sie etwas entwerfen, bedeutet das, dass Sie Ihre Anwendung für zukünftige Erweiterungen entwerfen, falls Sie den Code schreiben müssen (was gut ist ... das bedeutet, dass Sie Ihre Software erweiterbar und leicht zu pflegen machen).
>Etwas zu entwerfen bedeutet, dass du jetzt das ganze Stück schreibst ... ob du denkst, dass irgendjemand es tatsächlich benutzen wird oder nicht. Das ist nicht unbedingt eine schlechte Sache, aber es kann eine riesige Zeitverschwendung sein.
Sei vorsichtig was du tust.
Das hat etwas mit Perfektionismus zu tun. machen wir es perfekt, machen wir es für alle möglichen Zukunftsszenarien bereit.
Es hilft, pragmatisch und nüchtern zu bleiben, wenn man über die Chancen entscheidet, die es braucht: machen Sie dann entweder "Ja" oder "Nein". Vielleicht ist ein Nein.
Wenn es keine klaren Beweise dafür gibt, dass es benötigt wird (es steht auf der Tagesordnung, es wurde von einem Kunden verlangt) und Sie sehen, dass es besser ist, diese zukünftige Funktionalität in Ihrem aktuellen Design zu berücksichtigen, lassen Sie es vorerst aus.
Weil YAGNI ein Prinzip ist, kein Allheilmittel Bei der Softwareentwicklung geht es immer darum, viele Anforderungen auszugleichen. Es geht nicht darum, etwas richtig zu machen, sondern um nichts von vielen falsch zu machen. YAGNII alleine wird deinen Arsch nicht retten.
In diesem Sinne ist YAGNI da, um die folgenden Fallstricke zu vermeiden:
Das Abwägen konkurrierender Anforderungen ist schwierig. Aber das ist der Grund, warum - wie McConnell treffend feststellte - die Softwareentwicklung ein Engineering ist.
Weil andere Prinzipien auch Menschen sind Prinzip der anderen Prinzipien - grundlegendere IMO - ist das Prinzip der geringsten Überraschung und die Verkapselung der Komplexität : Die öffentliche Schnittstelle / Vertrag einer Entität sollte einfacher sein als ihre Implementierung - sonst , um eine Funktion richtig zu nennen, müsste ich mehr wissen, als ich es selbst tun müsste. Manchmal bedeutet dies, dass Ihre Implementierung abgeschlossen sein muss.
Ein Beispiel (vielleicht nicht sehr gut):
%Vor%ist ein einfacher Vertrag. OTOH,
%Vor%Ist nicht ein Vertrag, es ist eine Beschreibung der Implementation. (Man könnte argumentieren, wenn die Probleme das Ergebnis von übereifrigen YAGNI oder einfach schlechtem Design sind - aber vielleicht liegt das daran, dass Sie YAGNI komplett entwerfen würden)
Design tut nicht weh
Wird das Agile, die "Design-Phase", so etwas wie einen schlechten Ruf bekommen? Um jedoch schlimmer als gar keine Planung zu sein, müssen Ihre Pläne in der Tat katastrophal sein. Die größte Gefahr ist nicht wirklich schlechte Pläne, sondern versuchen, jedes Problem zu antizipieren und Anfrage zu ändern. YAGNI ist hier von unschätzbarem Wert.
Sie sind immerhin älter Ich kenne sie nicht - Ihre Tendenz kann auf die Indoktrination und die Angst vor Veränderungen in der Schule zurückzuführen sein. Oder vielleicht sind sie Senioren, weil sie ihren Job kennen - sie haben gelernt, welche Teile Sie jetzt lieber tun als später, und welche Teile können den Uncertanitäten der Zukunft geopfert werden.
Wenn Sie im allgemeinen denken, "es könnte [xyz] brauchen", dann sollte das explizit eine Rolle in dem spielen, was Sie programmieren. Selbst wenn Sie keine Unterstützung für xyz programmieren, sollten Sie so programmieren, dass Refactoring zum Hinzufügen von xyz-Unterstützung so praktisch wie möglich ist. Manchmal jedoch kann das bedeuten, etwas generischer zu machen, als es unbedingt sein muss. Zu wissen, wo man auf diesem Pfad anhalten kann, ist wahrscheinlich etwas, was nur domänenspezifische Informationen, die mit Erfahrung verbunden sind, Ihnen sagen können.
"Back to basics" und "Simple is good" sind ein paar Sätze, die mich daran erinnern, einfach weiterzumachen und zu verstehen, warum ich diese Funktion oder Erweiterung entwickle und nicht in Überdimensionierung oder Planung gehe für eine Million Dinge, die wahrscheinlich nicht passieren werden. Wo ich arbeite, wird mein Name oft verwendet, um etwas zu überentwickeln oder zu komplex zu beschreiben, z. "Sie haben JBed, wie man diese Seite baut." Ich versuche, dies in Schach zu halten, weil es manchmal nützlich ist, aber nicht oft genug, um es zu meiner üblichen Praxis zu machen.
Manchmal kann es auch hilfreich sein, eine Anforderung zu haben, die nicht in technischen Begriffen geschrieben ist. Das lässt mich wissen, was ich am Ende zeigen muss, und mir keine Sorgen um die feineren Details machen, z. Die Benutzer des Systems werden wahrscheinlich meinen Quellcode nicht lesen und meinen Gebrauch der von uns verwendeten Namenskonvention falsch machen. Sie kümmern sich darum, dass es funktioniert und tut, was sie brauchen und wollen.
Eine weitere Frage ist: "Haben sie wirklich danach gefragt?" und versuchen, die Annahmen, die man über die Funktionalität macht, zu minimieren. Wenn es nicht in der Liste ist, dann lassen Sie es aus, obwohl fragen Sie, ob sie es wollen.
YAGNI ist eher eine Frage, die man stellen muss. Wir als leitende Entwickler verletzen YAGNI die ganze Zeit. Es ist wirklich eine Frage der "Notwendigkeit". Brauchst du es? Definieren Sie "Notwendigkeit". Ich habe schreckliche Schlammbälle gesehen, die mit dem YAGNI-Dogma entstanden sind.
Nicht dass ich denke, YAGNI ist nicht nützlich ... es lohnt sich immer zu fragen "Brauche ich das".
Wenn Sie eine Bibliothek / ein Toolkit / eine Plattform / ein Framework erstellen, bekommt YAGNI eine andere Bedeutung.
Sie können nicht sicher sein, wie andere Entwickler Ihr Tool verwenden, und manchmal macht es viel mehr Sinn, flexibel zu entwerfen, damit Ihr Produkt in einer größeren Vielfalt von Szenarien verwendet werden kann. Vorwärtskompatibilität ist auch eine große Überlegung.
YAGNI gilt immer noch, aber das "it" tendiert dazu, eher auf einer Meta-Feature-Ebene als auf einer Feature-Ebene zu liegen.
Erinnern Sie sich daran, was Sie zu implementieren versuchen, und tun Sie nicht mehr. Sie können dies mit
tunNun, ich bin gestern auf dasselbe gestoßen und hatte einen großen Streit mit einem der älteren Entwickler. Ich versuche immer mit "was, wenn jemand dies nennt, was ist, wenn sich das ändert?" und er ist das andere Extrem. "Mach es einfach und schnell!"
Die Antwort liegt irgendwo zwischen seinem und meinem Ansatz. Wie kommen wir zum Mittelfeld? Zwischen dem Versuch, ein "perfektes" Design zu machen, das die Leute schätzen oder HASSEN würden, wenn sie in Zukunft etwas ändern müssten.
IMHO, die Antwort, zumindest beim Entwerfen eines Moduls, läuft auf grundlegende Prinzipien der objektorientierten Programmierung, Dinge wie klare Schnittstellen zu definieren. Schnittstellen sollten mit den Anforderungen des Kunden übereinstimmen. Die Hauptschnittstellen für das Modul sollten nichts haben, was irgendetwas "löst", außer was es in der Anforderung gibt. Wenigstens ein gewisses Maß an "Schnickschnack" hinzugefügt wegen "Was ist, wenn sich das ändert, sie brauchen das morgen usw." kann entfernt werden.
Alles, was Sie planen, weil Sie denken, dass dies morgen von jemand anderem benutzt werden könnte, muss stundenlang diskutiert werden! Du solltest gute Gründe haben, ein "Freebie" für SOMONE hinzuzufügen, der momentan noch keinen Namen hat!
Ich brauche noch eine definitive Antwort für diese Frage. Vielleicht von einem Architekten hier, der große Anwendungen entworfen hat und dieser Situation 100 Mal gegenüberstand:)
Es ist gut, Ihre Anwendungen so zu gestalten, dass zukünftige Features einfacher zu implementieren sind - aber implementieren Sie die Features erst dann wirklich, wenn Sie es benötigen. Wie Sie vorgehen, hängt vollständig von dem Projekt ab, an dem Sie arbeiten.
Ich finde, dass Peer-Reviews und Peer-Programmierung dabei helfen. Ein anderer Satz von Augen, die deine Argumentation in Frage stellen, wird schnell Dinge identifizieren, von denen du denkst, dass du sie brauchst, aber nicht wirklich.
Wenn du Agile befolgst, kannst du an den wichtigen Dingen arbeiten, bis du zu den Dingen kommst, die du nicht brauchst. Zu dem Zeitpunkt, an dem du zu den YAGNI-Sachen kommst, solltest du ein ziemlich fertiges Produkt haben. Es wäre dann Sache des Unternehmens, Ihnen zu sagen, dass Sie aufhören sollten, etwas zu entwickeln.
Wir haben eine Faustregel in unserem Unternehmen: Wenn wir über das Entwerfen eines neuen Features diskutieren, lautet die erste zu beantwortende Frage: "Wer möchte das wirklich?" Wenn ein Kunde dahinter steckt, versuchen wir zu verstehen, was er wirklich will und ob es andere Wege gibt, sein Problem zu lösen (anstatt ein neues Feature hinzuzufügen). Wenn ein Teammitglied nach dieser neuen Funktion fragt, sollte er gute Gründe haben dafür. Es gibt unter anderem Performance-Probleme und Marketing-Bedenken und wir versuchen erneut, die Anfrage vollständig zu verstehen und alle möglichen Alternativen zu besprechen, bevor wir unserer Code-Basis einige neue Funktionen hinzufügen.
Tags und Links design-patterns design yagni