Wenn Sie eine nicht triviale Anwendung erstellen, ist es am besten, sich darauf zu konzentrieren, die Dinge schnell zum Laufen zu bringen und Verknüpfungen im Code zu nehmen, beispielsweise Modelllogik mit Ihren Ansichten zu mischen und die Kapselung zu unterbrechen - typische Codegerüche? Oder nehmen Sie sich lieber die Zeit, um mehr Architektur zu entwickeln, und bauen Sie sie richtig. Dabei besteht jedoch die Gefahr, dass dieser zusätzliche Code nicht verwendet wird, da Ihr Entwurf ziemlich flüssig ist und Sie ihn möglicherweise wegwerfen müssen, wenn Sie Feedback erhalten in eine andere Richtung gehen?

Für den Kontext erstelle ich eine Desktop-Anwendung. Ich bin der einzige Entwickler und mache dies in Teilzeit, da ich einen Tagesjob habe. Bei der Arbeit versuche ich, die Dinge nach Zeitplan richtig zu machen. Aber für dieses Projekt, von dem ich erwarte, dass es sich verwandelt, wenn ich Feedback von Menschen erhalte, bin ich mir nicht sicher, ob das der richtige Ansatz ist. Ich habe diese Woche mehrere Stunden damit verbracht, ein Lehrbuch für das Model View Controller-Design einzurichten, um Änderungen am Modell der Ansicht mitzuteilen. Das ist im Allgemeinen großartig, aber ich bin mir nicht sicher, ob ich mehrere Ansichten zum Anzeigen der Daten benötige, und ich weiß, dass ich ohne die zusätzliche Architektur Dinge schneller hätte anzeigen lassen können. Mit vielleicht 10-15 Stunden pro Woche für das Projekt, denke ich, dass es Ewigkeiten dauern wird, um etwas zu bauen, das ich demonstrieren kann, wenn ich guten Software-Praktiken folge. Ich weiß, dass meine Benutzer gewonnen haben ' Es ist mir egal, dass ich MVC intern verwendet habe, sie wollen nur etwas, das ihr Problem löst. Aber ich war auch in einer Situation, in der Sie aufgrund von Abkürzungen so viele technische Probleme hatten, dass es unglaublich schwierig ist, den Code zu warten und neue Funktionen hinzuzufügen. Ich würde gerne hören, wie andere Leute diese Art von Problem angehen.

Baue es gut .

Es "schnell" zu bauen, ist ein logischer Irrtum, wenn man das Gesamtbild betrachtet. Es wird Sie daran hindern, es jemals gut bauen zu lassen, und irgendwann werden Sie von Fehlern und grundlegenden Architekturfehlern überfordert sein, die ein Refactoring verhindern oder sogar das Hinzufügen neuer Funktionen nahezu unmöglich machen.

Es gut zu bauen ist eigentlich das Gegenteil. Zuerst mag es langsamer sein, aber irgendwann werden Sie die Effizienzgewinne bemerken, wenn Sie sich die Zeit genommen haben, die richtigen Entscheidungen im Voraus zu treffen. Darüber hinaus können Sie sich leichter auf zukünftige Anforderungen einstellen (bei Bedarf umgestalten) und haben ein besseres Endprodukt, zumindest aufgrund weniger Fehler.

Mit anderen Worten (es sei denn, es handelt sich um einen einmaligen Vertrag): schnell bauen = langsam bauen, gut bauen = schnell bauen .

Es gibt auch etwas Wichtiges zu realisieren, wenn man es gut baut und eine Architektur entwirft. Du hast gefragt...

... aber das Risiko eingehen, dass dieser zusätzliche Code möglicherweise nicht verwendet wird, da Ihr Design ziemlich flüssig ist und Sie ihn möglicherweise wegwerfen müssen, wenn Sie aufgrund von Rückmeldungen in eine andere Richtung gehen?

Das ist kein wirkliches Risiko, wenn man "Architekturzeit verbringt". Architekturdesign sollte organisch sein . Nehmen Sie sich keine Zeit, eine Architektur für ein Teil zu entwerfen, bis es gerechtfertigt ist. Architektur sollte sich nur aus beobachteten und bestätigten Mustern in Ihrem Projekt entwickeln.

John Gall's Gesetz aus der Systemantik :

Ein komplexes System, das von Grund auf neu entwickelt wurde, funktioniert nie und kann nicht gepatcht werden, damit es funktioniert. Sie müssen von vorne beginnen und mit einem funktionierenden einfachen System beginnen.

Schnell, dann gut

Dies ist aus meiner persönlichen Erfahrung, die viele verschiedene Methoden ausprobiert hat.

Das Problem, dass Sie nur schnell arbeiten (und freigeben), besteht im Allgemeinen darin, dass Sie Feature für Feature in Ihre Anwendung integrieren. Seit der Veröffentlichung ist es sehr schwierig, grundlegende Änderungen an Ihrem Programm vorzunehmen. Langfristig zahlt man einen hohen Preis für nichts, was einer soliden Architektur zugrunde liegt. Es ist, als würde man auf Treibsand eine Bude bauen.

Das Programm dabei ist, dass Sie viel Zeit und Code verschwenden werden. Es ist, als würde man ein Herrenhaus ohne Baupläne bauen. Das Schreiben von Bewerbungen ist ein Lernprozess und meiner Erfahrung nach im Voraus kaum zu entwerfen. Das bedeutet, dass Sie viel überarbeiten müssen. Wenn Sie die ganze Zeit alles "gut" schreiben, werden Sie am Ende viel Code wegwerfen.

Also schnell, dann gut!

Die Hauptsache, wenn Sie anfangen, ist es, alles im Code festzuhalten, damit Sie alle Funktionen kennen und sehen können, welche Art von Architektur Sie unterstützen müssen. Eine weitere gute Sache an dieser Methode ist, dass ich Sie motivieren werde, da Sie schnell etwas am Laufen haben. Es ist auch wichtig, einige "Edge-Case" -Funktionen zu implementieren, da dies Auswirkungen auf Ihre allgemeine Architektur hat. Machen Sie sich in dieser Phase keine Mühe, Komponententests zu schreiben oder an Details zu arbeiten. Wenn Sie der Meinung sind, dass Sie in Zukunft mehrere Sprachen unterstützen müssen, implementieren Sie eine Plug-in-Architektur, die nicht nur schnell und schmutzig ist. Führen Sie einige Umgestaltungen durch, um die Anwendung handhabbar zu halten, aber nichts übermäßig.

Wenn Sie das Gefühl haben, einen funktionierenden "Prototyp" zu haben, ist es Zeit, mit dem Refactoring zu beginnen. Grundsätzlich möchten Sie die Anwendung so wiederholen, wie Sie es tun würden, wenn Sie von vorne anfangen und alles wissen, was Sie jetzt wissen. Das Wichtigste ist, die Architektur richtig zu machen und nicht alle Funktionen, die Sie in Phase 1 ausgeführt haben, erneut zu implementieren. Sie sollten jedoch die Architektur haben, die sie später unterstützt.

Auf diese Weise erhalten Sie eine Anwendung mit einer Soundarchitektur, die meiner Erfahrung nach so effizient wie möglich ist :)

Baue es

Schnell, wenn Time-to-Market wichtiger ist als Qualität

Gut, wenn Qualität wichtiger ist als Time-to-Market

Der schnelle Aufbau bringt Ihnen kurzfristige Vorteile und langfristige Verluste.

Wenn Sie es gut bauen, entstehen kurzfristige Verluste, aber langfristige Vorteile.

Wenn Sie es gut bauen, brauchen Sie Geduld und Weisheit, aber Sie werden belohnt.

Der schnelle Aufbau eignet sich nur für schnelles Prototyping und zum Wegwerfen. Langfristige Ziele können nur mit der richtigen Einstellung von Anfang an erreicht werden.

Bei Projekten, die Sie verteilen möchten, um sie anderen zur Verfügung zu stellen, würde ich immer Fehler machen. Eine durchdachte Architektur lässt sich bei Bedarf einfacher erweitern. Abkürzungen sind nur das Modell für die Ansammlung von technischen Schulden.

Es kann manchmal frustrierend langsam sein. Dinge, die es wert sind, getan zu werden, sind es wert, richtig gemacht zu werden.

Gut bauen = schnell bauen

Verknüpfungen drehen sich in der Regel um und beißen Sie noch schneller, als Sie denken. Manchmal sogar vor dem Mittagessen.

Über Ihren Kontext; nicht gleich abstrahieren. Halten Sie sich an YAGNI und entfernen Sie die Duplikate. Implementieren Sie dieses Ansichtsmuster, wenn Sie tatsächlich eine zweite Ansicht haben, und nicht, weil Sie glauben, dass Sie in Zukunft eine haben werden. Wenn diese zweite Ansicht eintrifft, ist die von Ihnen erstellte Abstraktion in der Regel viel besser als die, die Sie um dieses erste einzelne Vorkommen gemacht hätten.

Nun, wenn Sie bereits wissen, was Sie tun, schnell, wenn Sie dies nicht tun

Ich bin ein Forscher und schreibe viel Erkundungscode, bevor ich eine Ahnung habe, wie das Ganze aussieht oder wie sich das Projekt entwickeln wird. In diesen Fällen ist es schwer zu sehen, wie "gut" definiert werden sollte. Außerdem ist es normalerweise schwierig, all die kleinen Details und Möglichkeiten zu erkennen, wie die Dinge im Voraus erweitert werden könnten. Daher gilt das alte Sprichwort:

1. Bring es zum Laufen.
2. Richtig machen. Wenn Sie es auf den zweiten Platz bringen, haben Sie den Vorteil, dass Sie "richtig" besser definieren können, wenn Sie die Erfahrung gemacht haben, dass es funktioniert.

Baue es gut .. immer, aber gib die Illusion, schnell zu gehen

aber um es schnell zu machen, mach es einfach kleiner. Erstellen Sie eine kleine Teilmenge des Ganzen, die ausreichend aussagekräftig ist, um Feedback zu erhalten. Wenn Sie es in einem konstanten Tempo nach und nach hinzufügen, erhalten Sie den gleichen Vorteil wie beim schnellen Aufbau, ohne Ihre Seele an die Kettenreaktion schlafloser Nächte zu binden.

Ich denke, es sollte immer "gut gebaut" sein. Wenn Time-to-Market ein großes Problem ist, verwenden Sie einen inkrementellen Entwicklungsprozess. Im schlimmsten Fall verfügen Sie über ein Produkt mit weniger Funktionen, aber Sie müssen mindestens ein qualitativ hochwertiges Produkt ausliefern, das in zukünftigen Feature-Releases erweitert werden kann.

Balance

Es ist nicht praktikabel, entweder Ihren Code bis zur Perfektion zu entwickeln oder einen Code im Handumdrehen zu mischen, oder? Es geht wirklich darum, die richtige Balance zu finden. Was meiner Meinung nach zählt, ist, was Sie wann tun.

Ich denke, das Wichtigste dabei ist, dass der Kern der Anwendung, die grundlegende Struktur, wirklich gut aufgebaut ist. Luftdicht. Sobald dies erreicht ist, können Sie, abhängig von den Zeitbeschränkungen, Code zusammenstellen und später neu faktorisieren, und Sie können sich diesen Luxus leisten, da Sie dafür gesorgt hätten, das Fundament zu erhalten richtig, und es würde nicht schaden, Code neu zu faktorisieren.

Tun Sie das Einfachste, was möglicherweise funktionieren könnte. In Ihrem speziellen Fall wird Ihr Programm nicht sehr umfangreich, da Sie die einzige Person sind, die in Teilzeit daran arbeitet. Ich befürworte keine schlechten Manieren wie Missbrauch, unscheinbare Variablennamen usw., aber Sie sollten es nicht komplexer machen, als es sein muss. Vielleicht ist MVC nur ein Overkill für Ihr spezielles Projekt.

was ich erwarte, wird sich verwandeln, wenn ich Feedback von Leuten bekomme

Du hast es selbst am besten gesagt:

Aber ich war auch in einer Situation, in der Sie aufgrund von Abkürzungen so viel technische Schulden hatten, dass es unglaublich schwierig ist, den Code zu warten und neue Funktionen hinzuzufügen.

Wenn Sie wenig Zeit haben, sollten Sie sich nicht scheuen, bei Ihrem Arbeitgeber nach mehr Zeit zu fragen, um das Projekt mit den gleichen Überlegungen abzuschließen. Ich bin sicher, sie werden es dir gewähren. Trotzdem verstehe ich, wie frustrierend es manchmal sein kann, so hart an etwas zu arbeiten und nicht in der Lage zu sein, sehr viel von einem Ergebnis zu zeigen. Aber keine Sorge, Sie werden dort ankommen und es wird sich auf jeden Fall lohnen, es gut zu bauen, wenn Sie es tun.

Normalerweise mag ich es, die Struktur gut aufzubauen und Zeit zu sparen, indem ich mir keine Gedanken über bestimmte Implementierungsdetails mache. Wie du sagst, sie werden sich sowieso ändern. Die Idee hinter dem Aufbau einer gut gemachten Unterkonstruktion ist, dass Änderungen sehr schnell erfolgen können, sobald die Basis erstellt ist. Ich versuche mich darauf zu konzentrieren, in meinen Kursen so allgemein wie möglich zu sein und sie, wo immer möglich, wieder verwendbar zu machen. Normalerweise gebe ich dem Benutzer eine gut gebaute App, die nur die grundlegendsten Usability-Anforderungen erfüllt. Sobald ein Werkzeug in den Händen der Benutzer ist, erhalten sie alle Arten von Ideen. Es hat also keinen Sinn, zu weit voraus zu denken.

Baue es gut . Wenn Sie keine Zeit haben, reduzieren Sie den Funktionsumfang.

Gestalten Sie es so universell wie möglich. Entwerfen Sie beispielsweise eine Plugin-Architektur, auch wenn Sie wissen, dass nur ein Plugin zum ersten Mal verwendet wird. Verwenden Sie universelle Konfigurationsschemata (erweiterbare Konfiguration, Organisationssprache), auch wenn es am Anfang nur einen Parameter gibt. Es ist eine sehr gute Investition , und Sie können diese Investition nur zu Beginn des Projekts tätigen.

Konzentrieren Sie sich am besten darauf, die Dinge schnell zum Laufen zu bringen, und nehmen Sie Verknüpfungen im Code, wie z. B. das Mischen der Modelllogik mit Ihren Ansichten, das Brechen der Kapselung - typische Codegerüche? Oder nehmen Sie sich lieber die Zeit, um mehr Architektur zu bauen

In meinen Ohren, wie Sie es dort formulieren, listen Sie die beiden Extreme auf. Die erste Wahl, die Kapselung zu durchbrechen und die Modelllogik in die Ansichten zu integrieren, ist nur eine schlechte, langsame Programmierung. IMHO, diese Probleme zu lösen, ist nicht dasselbe wie mehr Architektur einzusetzen. Es sei denn, Sie sprechen davon, dass der UI-Code SQL-Anweisungen ausführt. Aber dann würde ich nicht sagen, mehr Architektur zu bauen, dann würde ich sagen, dass Ihnen Design und Architektur völlig fehlen und Sie sollten sich eine zulegen.

Wenn es um Architektur geht, würde ich die einfachste wählen, die Ihr Problem gerade löst, und sie erweitern, sobald Probleme auftreten.

Bsp: Benötigen Sie im Moment die Funktionalität, um Daten aus einer einzelnen Datenbanktabelle zurückzugeben? Ich würde mir keine Gedanken darüber machen, wie ich Daten aus verwandten Tabellen lade, obwohl ich weiß, dass das Problem irgendwann auftreten würde. Ich würde mir darüber Sorgen machen, wenn ich diese Funktionalität implementieren kann.

Für meine eigenen Projekte zur Entwicklung von Eigenheimen würde ich den folgenden Ansatz verfolgen: Erstellen Sie die einfachste mögliche Lösung, die das Problem löst, mit dem ich gerade arbeite, aber erstellen Sie sie gut. Ich würde dann die Lösung umgestalten, da mehr Komplexität benötigt wird. Das Befolgen der TDD-Praktiken macht das Refactoring sicher und vermeidet auch Codegerüche (es ist schwierig, gute Komponententests zu erstellen, wenn Sie die Kapselung aufheben).

Das ist übrigens auch mein Ansatz, wenn ich beruflich arbeite. ;)

Ich würde empfehlen, zuerst die Software zu starten, jeden Aspekt zu behandeln und die Software zuerst zu starten und dann nach und nach zu dekorieren und ihre Leistung zu verbessern

Normalerweise möchten Sie in der Mitte dieser beiden Kanten sein:

Erstellen Sie es gut = lebenskritische Echtzeit-Software, von der das Leben der Menschen abhängt. dh Software-Steuerung: Kernreaktoren, Dialysegeräte, MRT-Geräte usw.

Erstellen Sie es schnell = nutzlose Software, die niemand wirklich benutzt.