Richtige Mischung aus Planung und Programmierung für ein neues Projekt

Ich bin dabei, ein neues Projekt zu starten (ein Spiel, aber das ist unwichtig). Die Grundidee ist in meinem Kopf, aber nicht alle Details.

Ich möchte nicht ohne Planung mit dem Programmieren beginnen, aber ich kämpfe ernsthaft gegen meinen Drang, es einfach zu tun. Ich möchte vorher etwas planen, um zu verhindern, dass die gesamte App umgestaltet wird, nur weil eine neue Funktion, die mir einfällt, dies erfordert. Andererseits möchte ich nicht mehrere Monate (Freizeit) einplanen und damit beginnen, weil ich befürchte, dass ich in dieser Zeit meine Motivation verlieren werde.

Was ich suche, ist eine Möglichkeit, beides zu kombinieren, ohne dass das eine das andere dominiert. Sollte ich das Projekt in der Art von Scrum realisieren? Soll ich User Stories erstellen und diese dann realisieren? Soll ich funktionsgesteuert arbeiten? (Ich habe einige Erfahrung mit Scrum und der klassischen "Spezifikation zum Code" -Methode.)

Update : Wie wäre es, mit einem "Klick-Dummy" zu beginnen und die Funktionalität später zu implementieren?

Du bist auf dem richtigen Weg. Sie müssen nicht monatelang planen, aber Sie sollten auf jeden Fall einen Plan haben.

Die Planung hilft Ihnen dabei, Ihre Gedanken zu organisieren, Technologien zu identifizieren, die Sie möglicherweise benötigen, Probleme zu klären und Ihnen eine Roadmap zu geben, anhand derer Sie in messbare Ziele aufteilen können.

Darüber hinaus können Sie einige Tage planen, um festzustellen, dass dies Zeitverschwendung ist. Vielleicht stellen Sie bei der Planung fest, dass Sie aus Ihrer Liga herauskommen oder dass das, was Sie versuchen, nicht vermarktet werden kann. Es ist besser, das jetzt herauszufinden, damit Sie Ihre Zeit wieder in andere Ideen investieren können, die Sie haben, anstatt diesen Weg zu gehen, um sich im Wald zu verlieren, umgeben von fadenförmigen Code-Reben und Spuren fehlbarer Logik, die Ihr Gehirn verdreht in Knoten.

Planen Sie das minimal lebensfähige Produkt und implementieren Sie es. Hören Sie dann Ihren Benutzern zu, planen Sie die nächste logische Erweiterung und implementieren Sie diese. Wiederholen.

Egal wie viel Zeit Sie für die Planung und Gestaltung Ihres Programms aufwenden, am Ende schreiben Sie ohnehin immer Teile davon neu. Es ist wie die Schwerkraft, nicht klug, ihre Existenz zu leugnen.

Man muss erkennen, dass Refactoring ein normaler Teil der Entwicklung ist und es nur eine Frage der Entscheidung ist, wann Sie es tun. Warten Sie zu lange und Sie erhalten riesige Mengen Spaghetti, die Sie um ein vollständiges Umschreiben bitten. Nicht lustig.

Mein Vorschlag ist, ein wenig zu planen, aber so schnell wie möglich mit dem Codieren zu beginnen und Refactor, Refactor, Refactor, um den Code in Form zu halten. Das DRY-Prinzip (wiederholen Sie sich nicht) ist ein guter Indikator dafür.

Wenn ich in dieser Position bin, benutze ich manchmal TDD (Test Driven Development) und plane einige Tests für den komplexesten Teil des Systems, das ich entwickle. Alternativ kann ich wieder einen Pseudocode auf hoher Ebene für die komplexesten Bereiche zusammenstellen. Ich finde, dieser Prozess gibt mir einen losen Aktionsplan und hilft mir zu identifizieren, welche Bereiche wahrscheinlich am zeitaufwändigsten sind.

Für mich funktioniert dieser Ansatz, weil er irgendwo zwischen Codierung und Planung liegt. Sobald Sie Ihre Testideen und / oder Ihren Pseudocode haben, können Sie jeden logischen Abschnitt durcharbeiten und den Code implementieren. Ich gehe oft zuerst den schwierigsten Teil einer vorgeschlagenen Lösung an, da normalerweise der schwierigste Teil das Kernmerkmal der Anwendung ist und Sie jederzeit alle Schnickschnack verzögern können.

Da Sie kommentieren, dass sich der größte Teil des Codes in Ihrem Kopf befindet und Sie bereit sind, einzutauchen und zu programmieren, können Sie sich mit diesem Ansatz auf jeden Abschnitt konzentrieren, ohne dass Ihr Geist vom gesamten System getrübt wird.

Um es kurz zu machen, könnte man sagen: "Den schwierigsten Teil zuerst angehen, teilen und erobern, mit Pseudocode und / oder TDD-Plänen"!

Versuchen Sie einfach, den Code modular zu gestalten. Alles andere, was Sie planen, wird wahrscheinlich bei der nächsten Iteration verworfen.

Ich würde empfehlen, zumindest Ihre Ideen aufzuschreiben. Abhängig von der Größe des Projekts ist möglicherweise keine formelle Planung erforderlich. Wenn es jedoch überhaupt sehr groß ist, möchten Sie sich vielleicht Kopfschmerzen ersparen und ein paar Tage mit einer eingehenderen Planung verbringen.