Welchen Workflow befolgst du, um die Software zu entwerfen, die du schreiben möchtest? [geschlossen]

  

Was tun Sie, wenn Sie an persönlichen, mittelgroßen Projekten arbeiten, bevor Sie mit dem Code beginnen?

Ich spezifiziere die funktionale Spezifikation:

• Ich befürchtete, dass es zu einfach wäre, wenn ich gerade anfangen würde zu kodieren (was das "wie" ist), "warum" und "was" ich kodieren wollte (für "ziemlich komplizierte" Software über die Monate hinweg) oder Jahre, die es dauern könnte, um sich zu entwickeln).
• Ich wollte auch mehr oder weniger den "Umfang" dessen, was ich entwickeln würde, verstehen: um ungefähr (in einer Größenordnung) zu bewerten:
  • Wie groß wird es sein
  • Ob ich es fertigstellen könnte
  • Ob es sich gelohnt hat
  • Welche Teilmenge davon kann zuerst entwickelt werden

Aus Gründen des Risikomanagements füge ich hinzu, dass einige der Entwicklungen, die ich entwickeln wollte, mit einer Software verbunden waren, mit der ich nicht vertraut war; um das damit verbundene risiko zu minimieren, habe ich auch ein paar wegwerfprotokolle angefertigt.

  

Wie?

Ich skizzierte eine funktionale Spezifikation mit einem Stift. Einiges von dem, was ich geschrieben habe, war High-Level (ein Business-Level "Vision" -Dokument), und einige waren niedriger, eher wie Design (einige der UI-Details). Manchmal hörte ich auf und fragte mich, wie ich es organisieren sollte, aber dann fuhr ich fort, dass jede Seite zu jedem Thema mehr oder weniger zusammenhängend ist und dass ich später darüber nachdenken kann, wie man die Seiten organisiert (ähnlich wie dein Wiki, vielleicht).

Ich habe die Software-Architektur im Vorhinein spezifiziert und nicht spezifiziert:

• Ich beginne die Entwicklung mit einer grundlegenden Architektur (ein paar kleine Komponenten) im Hinterkopf und füge dann Code hinzu; und wenn ich Code hinzufüge, wenn eine Komponente zu groß und kompliziert wird, unterteile ich sie in mehrere kleinere Komponenten ... es ist ein evolutionärer Prozess ... wie es in Systemantik heißt, A KOMPLEXES SYSTEM, DAS FUNKTIONIERT, WIRD INVARIFIZIERT, AUS EINEM EINFACHEN SYSTEM GEARBEITET, DAS ARBEITET.
• Ich dokumentiere nicht die Architektur; oder vielmehr ist die einzige Dokumentation der Architektur der Code selbst: zum Beispiel die Art und Weise, in der Quellcode in Quellverzeichnisse, Namespaces und DLLs angeordnet wird.

Ich habe eine theoretische Begründung für die Architektur, wie sie jetzt ist, aber ich habe diese Gründe nicht dokumentiert:

• Ich bin der einzige Entwickler
• Die tatsächliche Architektur wird durch den Code
dokumentiert
• Die Gründe für die Architektur sind in meinem Kopf und sind durch Dinge wie die Namenskonventionen im Quellcode und die Abhängigkeiten der verschiedenen Komponenten [/ li] wiedererkennbar

Wenn (wenn ich) nicht der einzige Entwickler wäre, dann könnte ich denken, dass es sich lohnt, die Architektur und ihre Gründe zu dokumentieren.

Was ich oben über die Architektur der Software gesagt habe, gilt auch für die Daten , die die Software verarbeitet.

Wie für testing , codiere ich ein bisschen und teste es dann; oder schreiben Sie einen Test und kodieren Sie dann die Funktionalität, die diesen Test bestehen wird. Ich mache keine "Big Bang Integration", d. H. Monatelanges Schreiben ohne Tests.

Eine der größten Schwächen in meinem Prozess ist die Schätzung des Aufwands im Voraus und dann die Verfolgung der Implementierung gegen die Schätzung ... das ist einer der Unterschiede zwischen diesen "persönlichen" "Projektprozess gegen ein bezahltes Projekt, das ich für jemand anderen kommerziell machen würde. Ich bezweifle jedoch, dass dies gut ist: Wenn die Schätzung eine kommerziell bewährte Methode ist, dann sollte ich es vielleicht auch bei einem persönlichen Projekt tun.

Es gibt viele Menschen mit einer besseren Erfahrung als ich, um Ihnen bei den Einzelheiten hier zu helfen, aber ich habe einen Punkt, den ich denke, dass es immer wert ist, daran zu denken.

Sie müssen es nicht beim ersten Mal 100% perfekt machen. In der Tat, wenn Sie darauf zielen, werden Sie wahrscheinlich nie fertig sein. Die Realität ist, dass Sie das Design nicht vollständig verstehen werden, bis Sie das System einmal gebaut haben.

Fangen Sie einfach an, fahren Sie weiter, behalten Sie den Überblick über die Testabdeckung, und wenn Sie das System und seine Feinheiten besser verstehen, dann stufenweise umgestalten, um es zu verbessern .

Grundsätzlich die Bildschirme. Sie sind die Schnittstelle zwischen dem Benutzer und der Software. Also versuche ich jeden Anwendungsfall zu identifizieren (der Benutzer wird nach meinem Produkt suchen - der Benutzer wird ein Produkt zu seinem Caddy hinzufügen - der Benutzer wird seinen Caddy auschecken) und ich erstelle eine Kette von Bildschirmen für jeden von ihnen.

Beste Wünsche.

Ich finde ein leeres Stück Papier und ein Stift ist der beste Ausgangspunkt:

• skizzieren Sie einige grobe Diagramme
• notieren Sie einige Ideen / Notizen
• schreibe einen Pseudocode
• denke über die wichtigsten Anwendungsfälle nach
• denke an mögliche Probleme

Verbringen Sie nicht mehr als eine halbe Stunde damit und lassen Sie sich nicht in zu vielen Dokumentationen oder Vorabversionen stecken. Starten Sie die Programmierung, sobald Sie eine vage Vorstellung davon haben, wie Sie es tun möchten. Während Sie sich weiterentwickeln, bekommen Sie ein Gefühl dafür, ob der Code gut genug ist oder nicht. Wenn Sie nicht glücklich sind, denken Sie darüber nach, was Sie nicht mögen und beginnen Sie mit diesen Lektionen im Hinterkopf. Refactor oft und bald, je früher desto besser. Wenn sich etwas nicht "richtig anfühlt", ist es wahrscheinlich nicht.

1. Schreiben Sie die Anwendungsfälle wie Sie.
2. Wählen Sie 1 des Anwendungsfalls und implementieren Sie ihn vollständig und implementieren Sie nichts anderes. Dazu gehören Komponententests, Hilfe und Fehlerbehandlung - alles. Nennen Sie diese Version 1.
3. Implementieren Sie den nächsten Anwendungsfall. Dies kann nur Code hinzufügen oder erfordert ein komplettes Redesign. Es ist in Ordnung, du weißt, was du jetzt machst. Erstelle eine neue Version.
4. Wiederholen Sie Schritt 3.

1. Zeichnen Sie die Bildschirme
2. Zeichnen Sie die Datenrelationen (rdbms oder In-Memory)
3. Starten Sie die Codierung
4. Lather, Rinse, Repeat (oder im Programmiersprache GOTO 1)

Ich würde mit einer minimalen Implementierung beginnen und in jeder Iteration weitere Funktionen hinzufügen.