Das deutsche Python-Forum

Hallo allerseits,

ich programmiere seit einiger Zeit hobbymäßig in Python, habe mir diverse Tutorials angetan und hatte nie ein größeres Problem, im Zweifelsfall hiess es: Nicht verzagen, Google fragen!

Aber irgendwie habe ich mich an einem Punkt festgefahren, der mich jedesmal irgendwie gefrustet aufgeben lässt:

Die meisten Tutorials enthalten Probleme, die mit ein bisschen Nachdenken recht schnell gelöst sind: Nach ca. 1 Stunde rumprobieren stolpert man spätestens über die Lösung.

Aber wenn ich mich jetzt an eigene Projekte (na gut, nennen wir es Spielereien) wage, kommt über kurz oder lang der Punkt, an dem ich mit dem 'Trial & Error'-Prinzip nicht weiterkomme. Ich habe es bisher immer auf mangelndes Verständnis der Sprache zurückgeführt, aber nachdem ich mehrmals verschiedene Tutorials ausprobiert habe, denke ich eher, das es an mangelnder Planung liegt.

Wie plant man sein Projekt? Wenn ich eine Idee, eine grobe Vorstellung davon habe, was mein Programm machen soll, wie entwickle ich diese Idee weiter? Wie komme ich von der Idee zum fertigen Programm?

Ich hab im Netz verschiedene Sachen dazu gefunden, aber keine davon war für mich als Amateur und Nicht-Informatiker verständlich.

Ich wäre wirklich dankbar, wenn ihr mir Hinweise, Stichwörter oder Plaudereien aus dem Nähkästchen geben könntet

mfg
Jan, momentan ein bisschen frustriert

Hallo JC,
willkommen im Club.
Ich war auch nicht in der Lage aus den Tutos wirklich viel zu lernen, geschweigedenn sie komplett durchzuarbeiten.

Mir hat geholfen Scripte die ich brauche, anzupassen.
Das erste war ein Script um Bildergalerien zu erstellen. Da habe ich nichts wildes gemacht, nur die Standartvorgaben für Ordner, Größen oder Ausgabeformat geändert.

Als nächstes habe ich mir dann die Strings vorgenommen, die das Script für den Benutzer ausgibt. Da konnte man immer etwas basteln :-))

Der Sinn in dem Ganzen besteht darin:
- Übung mit den Werkzeugen neben der Sprache wie Doku, Fehlermeldungen, Texteditor(anpassen)
- einfach ein Gefühl für die Sprache und Erfolgserlebnisse bekommen
- da wo du schonmal rumeditiert hast, siehst du ganz nebenbei Standart-Konstrukte wie Schleifen oä - an die habe ich mich eher erinnert/verstanden als die Beispiele aus einem Tuto.

Und dann hat mich irgendwann der Ehrgeiz gepackt und ich wollte mein eigenes Script mit Gui und Kommandozeilenargumente.
Also habe ich mir etwas ausgesucht, was mir nicht allzu schwer erschien und ich tatsächlich auch benutzen würde: tk-thumbmaker
Nicht zu schwierig deswegen, weil ich das Konvertieren der Bilder selbst, aus dem Tuto zur Pil stibizt habe.
Ansonsten habe ich die Aufgaben die das Programm erledigen soll streng umrissen.
Odner(mit den Bildern) aussuchen -> höhe angeben -> Konvertieren oder Abbrechen.

Mit ordentlicher Hilfe hier im Forum[1] bin ich nun soweit dass alle Benutzerfunktionen die ich mir vorgenommen habe implementiert sind und das Programm funktioniert.

Also meine Empfehlung:
Bau dir ein kleines Script, das du auch selber brauchst/benutzt
In klitze-kleinen Schritten baust du das dann aus.
Ich verfahre nach dem Motto erst Doku schreiben dann Coden
Wenn du Funktionen deines Programmes oder Änderungen an diesem nämlich schonmal erklären kannst, kommst du dem ein oder anderen Logikfehler schon vor dem Coden aud die Schliche.

Was man sonst noch so braucht:
gute Musik!!!!!!!![2], Tee, Flatrate (für Online-Doku + Forum + google)

bzw nicht braucht:
Sonne oder gar Tageslicht, Vogelgezwitscher




cu Sebastian


[1] vgl Thread
[2] Dreadful Shadows, Paradise Lost, Tiamat, Lake of Tears, Bathory, New Model Army, Marillon, The Cure, Cemetary, Depeche Mode, Clan of Xymox, Project Pitchfork, REM, Queen, Mike Oldfield, ...

Es gibt wohl keine allgemeingültige Antwort auf diese Frage. Es kommt auch ein wenig auf das Projekt an. Ob man nur vorhandene Daten irgendwie verarbeitet und in anderer Form wieder ausgibt, oder ob ein Benutzer die ganze Zeit interaktiv mit dem Programm arbeiten muss usw.

Einfacher sind erstmal nicht-interaktive Programme. Wobei ich das von Mr_Snede noch zu dieser Gruppe zählen würde. Der Benutzer gibt am Anfang etwas ein und stösst dann einen Vorgang an, der linear abgearbeitet wird. Da kann man sich jeden Schritt der Reihe nach überlegen -- welche Daten werden benötigt, in welcher Form liegen sie vor, wie sollen sie am Ende aussehen und dann in kleinen Schritten, wie man dort hinkommt. Und dass kann man dann Schritt für Schritt umsetzen und jeweils ausprobieren ob die Teilschritte funktionieren wie man es erwartet.

Bei mir sieht es folgendermaßen aus:
Ich überlege zuerst ob das Projekt für mich überhaupt realisierbar ist, wenn nicht, dann überlege ich mir für das gegebene Problem andere Ansätze. Dann programmiere ich es erstmal so, dass es läuft, irgendwie. Wenn das mal geht, ist man über den Berg, dann kann man noch alle möglichen Features implementieren usw, usf.

Mr_Snede hat geschrieben:[2] Dreadful Shadows, Paradise Lost, Tiamat, Lake of Tears, Bathory, New Model Army, Marillon, The Cure, Cemetary, Depeche Mode, Clan of Xymox, Project Pitchfork, REM, Queen, Mike Oldfield, ...

Oha, auch Mike Oldfield Fans hier?

Hi,
Planen tu ich eigentlich keines meiner Projekte,
Ich programmiere weils mein Hobby ist, und wenn ich schon vorher weiss das meine Idee zu einfach ist und ich dabei nichts mehr lerne, hab ich eigentlich schon keinen Spaß mehr dran.

Eine Ausnahme sind Programme, die ich selber brauche.
Erst vor kurzem ist mein OPML Browser fertig geworden.
Oder meine Buch Datenbank.

Ich würd sagen, Mr Snede hat das recht gut auf den punkt gebracht. (mal abgesehen von dem, was er als Musik bezeichnet )
Nur wenn ich keine konkrete Vorstellung habe, mach ichs genau anders herum.
ich schreib zuerst GUI oder Templates und setzte das "Puzzle" dann von oben nach unten zusammen.

MfG
Andreas

Hi,

ich finde die Frage von JC eine sehr gute. Es ist schon richtig, daß man mit einer gewissen Planung viel Frust sparen kann. Und in dem Moment wo man über das "ich schreib mal schnell ein Skript" hinausgeht, lohnt es sich einen Plan zu haben. Dafür kann man tausenundein Argument angeben und auch viele verschiedene Ansichten zur besten Umsetzung haben. Ich finde aber besser als Bruce Eckel kann man es kaum zusammenfassen: http://www-h.eng.cam.ac.uk/help/tpl/lan ... c0022.html (tut mir leid, aber eine deutsche Übersetzung kenne ich nicht - es ist aber nur ein kurzes Kapitel).

Hoffe das sind Anregungen die helfen.

Gruß,
Christian

Sorry für meine späte Antwort, aber ich hatte einige Zeit keinen Zugang zum Internet. Bin aber jetzt wieder zu Hause. Was hab ich meinen Computer vermisst...

Erst einmal ein Dankeschön an alle, die geantwortet haben. Ihr habt mir viel zum Nachdenken gegeben, da werde ich erstmal einiges dran zu kauen haben.

Ich denke, ich werde erstmal Mr_Snede's Ansatz probieren, so in etwa hatte ich das schon vor, wusste aber nicht wie man da rangeht.
Parallel zieh ich mir den Artikel von Bruce Eckel rein, ich habe ihn schon mal überflogen... (danke für den Tipp, CM!).

Wenn ich irgendwas hinkriegen sollte, seid ihr die ersten, die es erfahrt

mfg
Jan, deutlich besser gelaunt