Idee umsetzen ohne Quelltext (Papier oder Objekte)

L

logoft

Well-Known Member
Hallo Leute,

mich interessiert wie man ein Programm planen sollte ohne dabei eine Zeile Code zu schreiben?

Wenn ich Ordnung halte wollte, sortiere ich alles. Ich könnte ein Blatt Papier nehmen und alles drauf schreiben. Ein Obstladen: Apel, Birnen, Kartoffeln, Kirschen. Auf dem Zettel schreibe ich die Variablen Kiste, Gewicht und Gemüse.

Oder soll ich ein Zettel schreiben Variablen und alle Variablen für das gesamte Programm sammeln? Wie bereitet man ein Programm sinnvoll vor? Wie soll ich die Ordnung vorbereiten? Was sollte ich wissen? Das habe ich bisher noch nicht lesen können. Auch wird bei dem Editor auch eine Ordnung empfohlen, aber wie man die Tabulatoren sinnvoll verwendet konnte ich bisher nicht lesen. Aber das wäredas Thema Editor und Code.
Mich interessiert das Thema Papier eigentlich sehr, weilich so Ideen vorbereiten könnte um sie eines Tages umzusetzen.

Für den Erforschungstest des Compiler "Obstladen" wäre es wichtig sich schon im Vorfeld Gedanken zu Variablen Lieferung, lkw-lang,lkw-kurz,Rampe-fuer-lang usw zu machen. Das heißt ich hätte jetzt genug Ideen zum Beispiel für ein Spiel Solitair, wo man über ein Spielstein hüpft und das überhüpfte zu entfernen. Ich könnte es schon längst im Kopf bzw auf Papier erdacht haben. Nur wie machen das andere? Damit es möglist nachvollziebar bleibt. Wenn man zum Beispiel in einem Projekt im Team zusammen arbeitet. OpenSource bietet sich da an.

Bevor ich mir etwas falsches aneigne oder ich mir den Weg in 10 Jahre mühsam erforsche, da frage ich vorher.

Und wie nennt man die Formen die für und oder oder stehen? Die mit Strichen den Entscheidungsweg zeichnen? Ich habe sowas auch als Pogramm gesehen, wüßte aber nicht wie man den Begiff dafür nennt.

Danke
 
Meine Persönliche Meinung dazu ist dass UML & Co eher verwirren als dass sie einen weiter bringen, besonders Anfänger. Letztlich steht da eine top-down Sichtweise der Programmierung dahinter die vielleicht bei großen Projekten Sinn macht, aber kaum bei normaler Programmierung. Hier arbeitet man sinnvollerweise bottom-up, d.h. man fängt mit den grundlegenden Funktion an und baut daraus dann geeignete Abstraktionen auf denen man dann weiter aufbaut.

Füi größere Projekte sollte man sich mit Idiomen beschäftigen die du unter dem Stichwort "Pattern" findest. Aber das macht erst Sinn wenn du die Grundlagen hinter dir hast.

Wenn ich gerade mal keinen Compi zur hand habe schreibe ich mir Ideen gelegentlich einfach in Pseudo-Conde auf. Das erscheint mit sinvoller als eine graphische Repräsentation in Nassi-Schneidermann oder was auch immer.
 
rubricanis schrieb:
Meine Persönliche Meinung dazu ist dass UML & Co eher verwirren als dass sie einen weiter bringen, besonders Anfänger. Letztlich steht da eine top-down Sichtweise der Programmierung dahinter die vielleicht bei großen Projekten Sinn macht, aber kaum bei normaler Programmierung. Hier arbeitet man sinnvollerweise bottom-up, d.h. man fängt mit den grundlegenden Funktion an und baut daraus dann geeignete Abstraktionen auf denen man dann weiter aufbaut.

Füi größere Projekte sollte man sich mit Idiomen beschäftigen die du unter dem Stichwort "Pattern" findest. Aber das macht erst Sinn wenn du die Grundlagen hinter dir hast.

Wenn ich gerade mal keinen Compi zur hand habe schreibe ich mir Ideen gelegentlich einfach in Pseudo-Conde auf. Das erscheint mit sinvoller als eine graphische Repräsentation in Nassi-Schneidermann oder was auch immer.
Zum Vergrößern anklicken....

Ich denke eher daran, wenn ich ein Ordner aus Papier anlege und dann Ideen aufschreibe ohne programmieren zukönnen.

Kirsche essen:
Auf Sommer warten
hole Eimer
hole Leiter
kletter rauf
plücke Kirschen
esse Kirsche
Kirsche entkernen
Kuchen backen

Sodaß ich alles vorbereite um eines Tages einen Code zu erstellen. Mir geht es um eine sinnvolle Vorbereitung. Mir ginge es auch darum ein Programm eines Tages zu programmieren um bei Änderungen es als Papier lesen zu können. Mir geht es auch darum zu denken wie ein Programmierer, um mir vorher eine Struktur anzueignen damit andere mich erstehen könnten. Also sinnvolle Schubladen interessieren mich.

Wenn ich die Ideen am Computer mit den Körpern ausdenke, dann hilft man das bestimmt sehr Entscheidungen zuprogrammieren. Gehe zu wenn a erfüllt ist, breche ab wenn C = ist.

Deshalb fände ich es gut zu wissen die Denkweise für ein Programm auf Papier zu schreiben.
 
logoft schrieb:
Sodaß ich alles vorbereite um eines Tages einen Code zu erstellen.
Zum Vergrößern anklicken....
Damit verschiebt man das Problem nur in die Zukunft. Du hast an anderer Stelle geschrieben:
Das ich soviel anpacke und bringe nie was auf die Beine nervt mich gewaltig.
Zum Vergrößern anklicken....
Du packst den Stier nicht wirklich an den Hörnern, sondern machst Pläne. Kein Wunder dass da nichts draus wird. So lange man nur denkt und nichts tut, bewegt man sich nur im Kopf und weiss überhapt nicht was Sache ist. Glaube mir: Wenn du mal die Grundlagen begriffen hast wirst du ganz andere Ideen haben als "Kirschen essen" oder was auch immer. Schwimmen lernt man eben nicht im Trockenen.:rolleyes: Und erst wenn man schwimmen kann weiß man was möglich und denkbar ist und was nicht.

Fang einfach an, alles andere ist Zeitverschwendung [*], und dann kann man weiter sehen...

[*] Und auch meine oder die von anderen hier im Forum.
 
Bei komplexeren Programmen ist es meiner Meinung nach unabdingbar sich vorher umfassende Gedanken "auf Papier" zu machen um nicht später mehr mit "Code anpassen" beschäftigt ist als mit der eigentlichen Aufgabenstellung. Nur so können, meiner Meinung nach, auch die richtigen Abstraktionstiefen gefunden werden.

Zunächst solltest du natürlich deine Anforderungen an das Programm aufschreiben. Was soll es machen, unter welchen Bedingungen soll es seine Arbeit verrichten, wie sollen ggf. Schnittstellen aussehen etc. Das was man praktisch in ein Lastenheft schreiben würde.

Wenn du dich dann an die Umsetzung machst solltest du deine Probleme strukturieren. Technische Fragen wie Trennung von z.B. Client und Server-Teilen oder Frontend und Backend sollte man frühzeitig beantworten, zumindest grob.
Wenn du dann dein Programm in UML und Konsorten entwickelst wirst du relativ schnell Schnittstellen verschieben umdefinieren etc was später im Code unnötig aufwändig wäre. Welche Art der Notation man wählt muss man ausprobieren. Ich persönlich finde für Objektorientierte Lösungsansätze UML gut geeignet, ich verwende jedoch eine "abgespeckte eigene Notation". Ablaufpläne etc finde ich für "Geradeausläufer" in funktionalen Ansätzen gut. Das ist aber wie gesagt Geschmackssache.

Das sieht nun vielleicht übertrieben formalistisch aus, aber für ein vernünftiges Projekt kommt man anders, meiner Meinung nach, nicht wirklich effizient voran. Um Programmieren zu lernen halte ich es allerdings nicht für den richtigen Ansatz mit UML anzufangen. Hier sollte man sich Algorithmik näher bringen und mit einer einfachen Sprachen und einfachen Beispielen rumprobieren. Wenn das Verständnis hierfür vorhanden ist kann man all die formalen Werkzeuge auch erst verstehen und richtig einsetzen.
 
@Rakor: Das Problem ist doch dass Prgrammentwicklung ein rekursiver Prozess ist und man vorab nicht weiß ob die funktionale Dekomposition so funktioniert wie man sich das vorstellt. Deswegen entwickelt man in dynamische Sprachen wie Lisp, Smalltalk & Co Prototypen und variiert die Komponenten add hoc wenn sich Fehler im Design zeigen. Das gleiche macht man in Scriptsprachen wie Lua. Erst wenn das Ganze zufriedenstellend läuft bricht man es endgültig in C-Libraries auf, - ggf. bis zu dem Punkt dass von Lua nichts mehr vorhanden ist.[*]

Klar, in kompilierenden Sprachen wie C/C++ ist das mangels REPL so nicht möglich. Aber auch hier dekomponiert man das Ganze zunächst vorzugsweise ein Libraries und stellt die dann zusammen.

Natürlich muss man vorab wissen was man will, aber dazu reicht ein DIN A4 Blatt. ;)


.[*] Das Problem ist hier dass es allzuoft beim Prototyp bleibt und dann das Laufzeitverhalten und der Resourceverbrauch suboptimal bis besch... ist. Außerdem muss man mindestens 2 Sprachen beherrschen.
 
Stimmt, normalerweise macht man sich vorher ein paar Gedanken, wofür man das Programm unbedingt braucht(und selber entwickeln muss) und baut sich Schnittstellen so, das an den interessanten/ausgewählten Punkten erweiterbar ist. Aber gerade bei Hobbyprojekte, unter 10K, wovon vermutlich man selbst der einzige Nutzer ist, macht aufwendige UML und OOD kaum Sinn.
Wenn ich ein Tool brauche, dann schreib ich es mir, dann sollte es lieber heute als morgen zur Verfügung stehen. Normalerweise kombiniere ich EVA und ein paar Use Case Diagramme, schreibe mein Programm Top-Down herunter. Wichtig, möglichst früh müssen die Sachen funktionieren und die Bugs und Limitierungen werden benannt bzw. behoben. Alles darüber hinaus mag dem Uni-Dozenten freudig stimmen, brauch ich aber nicht. 90% aller Java-Projekte und deren Konvertierungen auf andere Sprache sind deshalb Sondermüll und total engineered weil irgendein Hans gedacht hat, zu allem muss es Schnittstellen geben und nur die mit den geilsten Software-Pattern kommen in den Himmel.
Schließlich ist alles was wir machen immernoch ein Hobby, welches Spaß machen muss.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben