Strukturierte Programmierung

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo,
ich beschäftige mich schon seit einger Zeit mit Programmierung und Programmiersprachen (Visual Basic, C++ // JavaScript, PHP, HTML // Macromedia Flash etc)

Nun interessiert es mich mal, wie man richtig programmiert, also die Vorgehensweise und die Strukturierung des Quellcodes.
Auch wie ich mir den Code schon klein und sinnvoll halte.

ein Beispiel:
Ich möchte zur Übung mittels Flash und PHP/MySql eine Art Monopoly programmieren.

Wie fange ich an?

Ich erstelle mir einen Ablaufplan
Problem: mir fallen später viele verbesserungen ein

Ich gestalte erst das Spielbrett?
Problem: mir fällt während der programmierung ein was ich besser machen könnte oder ich kann aufgrund des Spielbretts etwas nicht umsetzen

Ich programmiere den Quellcode
Problem: Der Code wird zwischendurch immerwieder erweitert, es fallen immer neue Probleme auf, der Code wird unübersichtlich.

Also wie geht man am besten vor? oder wie geht ihr solche sachen an?

Danke und Gruß

Marcel

#2

Hallo,
es gibt eine ganze Menge Literatur zum „idealen“ Vorgehen bei Softwareentwurf und Umsetzung. Aus meiner Sicht hängt die Wahl der Methodik vom eigenen Problemlösungsverhalten und der Wahl der Programmiersprache ab. Ich kann z.B. gut Probleme auf abstrakten Level spezifizieren und sie nachfolgend schrittweise verfeinern. Das sich dabei ggf. Änderungen an der abstrakteren Sicht ergeben ist normal. Ebenso daß man bei komplexeren Problemen nach einer Zeit erkennt, daß es einen simpleren Ansatz gibt und Entwurf + Umsetzung gänzlich neu gestaltet. Insbesondere heißt das, daß Dein striktes schrittweises Vorgehen für mich nicht praktikabel wäre.

Gruss
Enno

#3

Wie fange ich an?

Ich erstelle mir einen Ablaufplan
Problem: mir fallen später viele verbesserungen ein

Ich gestalte erst das Spielbrett?
Problem: mir fällt während der programmierung ein was
ich besser machen könnte oder ich kann aufgrund des
Spielbretts etwas nicht umsetzen

Ich programmiere den Quellcode
Problem: Der Code wird zwischendurch immerwieder
erweitert, es fallen immer neue Probleme auf, der Code wird
unübersichtlich.

oder wie geht ihr solche
sachen an?

Hallo! Bei grösseren Programmen, fällt mir das am leichtesten, wenn ich stur in ‚Problem-Schichten‘ programmiere. (Mir viel gerade kein besseres Wort ein *g*)

D.h. Du teilst dein Monopoly-Problem erst in die grösseren Probleme ein. Ich kenne mich mit Monopoly leider nicht aus (spiel nur Hotel und DKT *g*) darum tu ich mich mit Beispielen schwer. Aber zb.: Spielplan ausgeben
Benutzereingaben verwalten
…
Diese Probleme programmierst du mal stur aus. Dabei kannst du Funktionen verwenden die es noch gar nicht gibt (zb. eine Funktion GibHotelAus, GibKegelAus usw.). Dann gehst du in die nächste Problemschicht. also zb bei Spielplan ausgeben: Wie gebe ich ein Hotel aus, wie gebe ich einen Kegel aus usw. So gehst du Schicht für Schicht vor.

Das ganze solltest du zuerst mal ‚im Kopf‘ machen, also auf Papier. Erst dann drauf los Programmieren. Wenn dann beim Programmiern noch Probleme auftauchen, fügst du einfach die dementsprechenden Funktionen ein. Du musst dann nur die ‚künftigen‘ Schichten umbauen und nicht im programmierten Code rumpfuschen.

HTH,
Bettina

#4

Hallo Bettina,

Das ganze solltest du zuerst mal ‚im Kopf‘ machen, also auf
Papier. Erst dann drauf los Programmieren. Wenn dann beim
Programmiern noch Probleme auftauchen, fügst du einfach die
dementsprechenden Funktionen ein. Du musst dann nur die
‚künftigen‘ Schichten umbauen und nicht im programmierten Code
rumpfuschen.

danke, das hört sich lecker an *g*
werde das mal ausprobieren…

Gruß Marcel

#5

Hallo Enno . Ebenso daß man bei

komplexeren Problemen nach einer Zeit erkennt, daß es einen
simpleren Ansatz gibt und Entwurf + Umsetzung gänzlich neu
gestaltet. Insbesondere heißt das, daß Dein striktes
schrittweises Vorgehen für mich nicht praktikabel wäre.

genau das ist es, so geht’s mir auch ich werfe, grade kleinere programe 3 bis 4 mal um und gestalte sie neu, den zeitaufwand möchte ich durch ideales vorgehen minimieren.
Ansonsten mache ich es wohl so ähnlich wie du…

Hast du evtl. einen Literatut-Tipp parat?

Danke und Gruß

Marcel

#6

Hallo Marcel,

mir geht es genau wie Dir! Ich kann kaum anhand einer theoretischen Planung ein Programm schreiben, mit dem ich zufrieden wäre. Bei mir muss ein Programm wachsen, es muss sich entwickeln. Programmieren ist für mich eher eine Form der Evolution. Ein Konzept braucht’s natürlich schon. Aber das darf man - denke ich - nicht für unabänderbar nehmen, wenn man dann „coded“.

Ich glaube, das ist auch generell so, abweichend von die idealisierten Lehrmeinung, wie Programmierung auszusehen hätte. Im Prinzip ist jede auch professionelle Programmentwicklung sowas, nur dass ab und zu mal ein „Fix“ gemacht wird, der dann als Update oder neue Version verkauft wird. Schon die Geschichte von Windoof selbst bietet hier ein Paradebeispiel. Die Ideen kamen immer während der Entwicklung, wurden dann in der nächsten Version implementiert, wobei es wieder andere Ideen gab usw.

genau das ist es, so geht’s mir auch ich werfe, grade kleinere
programe 3 bis 4 mal um und gestalte sie neu, den zeitaufwand
möchte ich durch ideales vorgehen minimieren.

Die lehrbuchmäßigen Planungen vor dem Coden nehmen fast die gesamte Zeit der Programmentwicklung in Anspruch, und das ist nun mal Zeit, die’s braucht. Das Coden selbst ist dann nur noch der letzte Rest, das i-Tüpfelchen. Bei den Planungen aber ändert sich die Struktur ja noch ganz dynamisch, durchaus rückwirkend auf mehreren Ebenen. Ich sehe das so, dass diese Planungen genausogut auch _durch_ das und _mit_ dem Programmieren gemacht werden können. Dabei fließen Planen und Coden praktisch ineinander, aber ist das so tragisch?

Ansonsten wäre ich auch dankbar für Tipps, wie man das effektiver machen kann.

Grüße,
Jochen

#7

Schon die Geschichte von Windoof selbst bietet hier ein
Paradebeispiel. Die Ideen kamen immer während der Entwicklung,
wurden dann in der nächsten Version implementiert, wobei es
wieder andere Ideen gab usw.

darum ist windoof auch so instabil :wink:

Die lehrbuchmäßigen Planungen vor dem Coden nehmen fast die
gesamte Zeit der Programmentwicklung in Anspruch, und das ist
nun mal Zeit, die’s braucht. Das Coden selbst ist dann nur
noch der letzte Rest, das i-Tüpfelchen. Bei den Planungen aber
ändert sich die Struktur ja noch ganz dynamisch, durchaus
rückwirkend auf mehreren Ebenen. Ich sehe das so, dass diese
Planungen genausogut auch _durch_ das und _mit_ dem
Programmieren gemacht werden können. Dabei fließen Planen und
Coden praktisch ineinander, aber ist das so tragisch?

Wenn du es schaffst, den Code ordentlich zu strukturieren und jedes Teilproblem getrennt vom ganzen zu programmieren (dh. man könnte eine Funktion auch in einem ganz anderen Zusammenhang verwenden - aber mit demselben Teilproblem - und sie würde noch immer funktionieren), wenn auch ein zweiter dein programm nachvollziehen kann, wenn man den code schnell und unkompliziert erweitern kann, dann kannst du natürlich gleichzeitig planen und programmieren und dir ne Doku sparen.

Ab einer gewissen Projektgrösse wirst das aber nicht mehr schaffen. Dann investierst du vermutlich 10 mal mehr Zeit ins Erweitern des Programmes als du für die Doku gebraucht hättest. (Wenn du es nicht gleich neu programmieren musst…)

Natürlich kann man während der ‚Programmierphase‘ noch änderungen am ursprünglichen Design vornehmen (warum auch nicht?) aber ich denke eine Planung auf Papier ist doch schneller umgebessert, als ein ganzes Programm.

Kommt aber natürlich immer auf die grösse des Programmes an.

Viel spass beim proggn,
Tina

#8

Hallo Marcel!

Ich nehme jetzt mal an, daß Du Dich mit objektorientierter Programmierung noch nicht auseinandergesetzt hast. Diese hat den Vorteil, daß Du, im Falle von Änderungen, manchmal nur eine Klasse ersetzen mußt.

Die gesamte Objektorientierung kann ich Dir in ein paar Zeilen (leider) nicht vermitteln, aber der Ansatz ist der Realität entsprechend.
Hier ein Beispiel:
Du hättest also erstmal eine Klasse ‚Spieler‘ der Spieler hat einen Namen, eine Methode ‚würfeln‘, er besitzt Häuser und Hotels, er befindet sich auf einem Feld, und er hat die Methoden kaufen, verkaufen und Geld einnehmen.
Dann hast Du eine Klasse ‚Würfel‘, mit nur einer Methode (eben würfeln).
Hinzu kommen die Klassen ‚Spielfeld‘, ‚Haus‘, ‚Hotel‘, ‚Bank‘ und ‚Chance‘.
Wenn Du Dich näher damit beschäftigst, wirst Du merken, daß es zwar anfangs sehr kompliziert wirkt, am Ende ist es aber einfacher als die prozedurale Programmierung.
Wenn Du in C++ fit bist, dann müßte Dich die Objektorientierung ja schonmal gestreift haben, denn in C++ kann man schwer nicht objektorientiert programmieren (ebenso in JAVA).
Wenn Du mehr Info’s dazu willst, poste, aber erwarte Dir bitte nicht von mir, daß ich Dir alles zur Objektorientierung beibringe.

Grüße

Gollum

#9

Hallo Gollum

Wenn Du mehr Info’s dazu willst, poste, aber erwarte Dir bitte
nicht von mir, daß ich Dir alles zur Objektorientierung
beibringe.

Danke nicht nötig, mit der Info und meinem C++ Buch *g*
werde ich wohl etwas weiterkommen.

ansaonsten melde mich doch nochmal

Gruß

Marcel