Also privat bevorzuge ich die VHIT Methode um größere Softwareprojekte zu realisieren.  *spass*

Naja du solltest dir zu Anfang überlegen was reinkommt und was rauskommen soll.
Und das möglichst genau definieren.
Diesen Schritt machst du für jedes einzelne Modul und jede Sub die du brauchst.
Das alles natürlich schriftlich festhalten.
Ein Ablaufplan ist sicher auch brauchbar wenn die Logic entsprechend kompliziert ist. Wobei ich da zugeben muss, dass ich eine Logik die mit so lustigen Pfeilen und Kästchen visualisiert wird, manchmal langsamer verstehe als ein broken Code.

Wenn du dann noch Lust hast kannst du die Details mit einem Struktogram vorbereiten. Wenn das alles sorgfältig gemacht wurde, dann brauchst du im Grunde das alles nur noch mit deiner Programmiersprache "abzuschreiben" bzw. umzusetzen. So besagt das die Theorie, aber ob es in der Praxis immer so funktioniert...

Bei richtigen Projekten werden über 2/3 der veranschlagten Zeit für die Planung benötigt, das Coden selbst ist nur recht wenig. Den von dem 1/3 gehen dann auch noch mal einige Prozente für's testen drauf.

Aber macht ja auch Sinn wenn man sich schon vor dem Coden Gedanken macht, viele Fehler die sonst das neuschreiben mitsichbrignen, kann man so vorher entdecken.

Heiner Kuhlmann hat 2004 beim Perl Workshop einen Vortrag über "rekursives Design und Implementierung von komplexen  Perl-Programmen" gehalten, der da auch einige interessante Aspekte aufgezeigt hat.

Der eine Weg ist die kleinsten Einheiten fertig zu entwickeln. Nachteil: man sieht keine oder nur kleine Fortschritte
Der andere Weg wäre das Grundgerüst zuerst zu erstellen und dieses mit Dummies zu füllen, welche nach und nach durch funktionierenden Code ersetzt werden. Das hat den Vorteil dass man schon in einem recht frühem Entwicklungsstadium was funktionierendes hat.

greetz & fetten Segen
manu\n\n

<!--EDIT|pfuschi|1113171560-->