Projektplanung / Prophylaxe von Fehlern / Erleichterungen

[CrackPod]

Hallo,

ich habe mir zum Zeitvertreib vorgenommen einfach mal was (halbwegs) nützliches(?) zu tun. Größtenteils wird das wahrscheinlich eher ein Projekt werden, aus dem ich lernen werde, aber vielleicht freut sich irgendwann der ein oder andere drüber
Worum es geht:
Ich will einen Fork/Remake von Druglord2 schreiben, da es meines Wissens nach keine quelloffene Version gibt. Außerdem stört es mich, dass es prinzipiell nur um den Drogenhandel geht und ich finde, dass man aus dem Spiel noch mehr raus holen kann.
Was ich vorhabe:
Das ganze wird wohl erstmal als GTK-Programm bzw "Spiel" erscheinen. Wenn danach jemand anderes oder ich selber Lust/Zeit hat weitere GUIs dazu zu schreiben, kann das gern gemacht werden(soll ja modular werden )
Ansonsten soll man auch über INI Dateien(o.ä.) neue Ereignisse, die Waren, mit denen man handeln kann u.v.m. ändern können.
(Für weiter Vorschläge bin ich gern zu haben )
Stand:
Bisher habe ich noch nicht viel geschrieben. Um genau zu sein nur einmal die Klasse, die einmal die Waren enthalten soll grob angeschnitten.
http://paste.pocoo.org/show/5769/ <-- da is sie.
Und darum geht es mir primär erstmal. Damit ich nämlich nicht sofort wieder die Lust an dem Projekt verliere will ich wissen, ob das bis jetzt sinnvoll realisiert ist(vom Ansatz her). Und evtl Vorschläge, wie man das sinnvoller realisieren kann. Mit dem Projekt will ich mir schließlich auch einige Programmierkniffe beibringen.
Ich weiß es ist nicht viel Code, aber ich bin mir nicht sicher ob die Verwendung von New-Style Klassen sinnvoll is, sowie die Container-Klasse.

Isn bisschen viel zu lesen Hoff, ihr lest es trotzdem und gebt eure Meinungen zum Besten.
Mir sind auch gerne allgemeine Tipps recht. Also im Bezug auf Projektplanung und -management.(Ich hab mir mal Trac und SVN installiert, um damit mal Erfahrungen zu sammeln)
LG Tobias

[veers]

Vermutlich ist das jetzt nicht was du hören willst noch was allgemein als best practice durch gehen kann aber:

Schreib einen Prototypen so schnell wie möglich. Dabei dürften sich die meisten Problem zeigen und du wirst viel dabei lernen.
Und dann schreib das ganze nochmal neu in ruhe und schön. Mit dem wissen das du aus dem Quick & Dirty Prototypen gewonnen hast wirst du dann mit viel weniger Planung und Überraschungen das Game sauber implementieren können.

Das empfiehlt sich vor allem auch gut wenn man (auf dem Gebiet) noch weniger Erfahrung hat.

[CrackPod]

Eigentlich gibt es nichts was ich nicht hören will. Also danke für den Tipp
Ich dachte mir halt, es ist evtl praktisch/vorteilhaft ganz allgemeine Tipps, wie man ein Projekt angeht, einzuholen.
Dabei hab ich mich gleich mal gefragt, ob das kleine Würstchen, was ich fertig hab, sinnvoll ist, oder eine Klasse reicht usw
Was mich auch interessieren würde, da mir das im Verlauf des Projekts sicher was bringt:
* Kann/sollte ich für diese beiden Klassen unit tests schreiben
* Wie mache ich das
LG

[gerold]

Schreib einen Prototypen so schnell wie möglich. Dabei dürften sich die meisten Problem zeigen und du wirst viel dabei lernen. Und dann schreib das ganze nochmal neu in ruhe und schön.

Hallo!

Das kann ich nur unterstreichen. Als Anfänger oder fortgeschrittener Anfänger lernt man daraus enorm viel. Man muss aber unbedingt im Hinterkopf behalten, dass das Programm sowiso noch einmal neu implementiert wird, so dass man sich nicht zu sehr mit Kleinigkeiten aufhält. Wichtig ist dabei auch, dass man den Code gut dokumentiert. Das erleichtert später die Neuimplementation erheblich.

Programmiere abgeschlossene Blöcke. Diese kannst du dann einzeln austesten und wenn dir nicht gefällt, was du so programmiert hast, kannst du den Block ganz einfach durch eine Neuimplementation tauschen.

Daraus ergibt sich auch eine etwas abgespeckte Art der Neuimplementation. Statt das ganze Programm neu zu implementieren, kannst du nach und nach die einzelnen Programmteile neu schreiben.

Dabei ist es auch keine schlechte Idee, z.B. Subversion als Coderepository einzusetzen. Damit kannst du immer wieder zu einem Stand zurück kehren.

mfg
Gerold

[lutz.horn]

* Kann/sollte ich für diese beiden Klassen unit tests schreiben
* Wie mache ich das

Du sollst für jede Klasse Unittests schreiben, am besten mit testgetriebener Entwicklung. Für Python gibt es in der Standardbibliothek unittest, seine Anwendung wird z. B. in Dive into Python beschrieben.

[lutz.horn]

Dabei ist es auch keine schlechte Idee, z.B. Subversion als Coderepository einzusetzen. Damit kannst du immer wieder zu einem Stand zurück kehren.

Für die Quellcodeverwaltung empfiehlt sich ein Blick auf Mercurial. Es benötigt keine Repository-Installation, folgt dem modernen verteilten Ansatz und ist in Python geschrieben

[veers]

Für die Quellcodeverwaltung empfiehlt sich ein Blick auf Mercurial. Es benötigt keine Repository-Installation, folgt dem modernen verteilten Ansatz und ist in Python geschrieben

Vorteile gegenüber von git?

[lutz.horn]

Vorteile gegenüber von git?

Auch wenn es mir nicht wichtig ist, scheint die Windowsunterstützung von Mercurial besser zu sein. Git läuft nur unter Cygwin etc.

[gerold]

Dabei ist es auch keine schlechte Idee, z.B. Subversion als Coderepository einzusetzen. Damit kannst du immer wieder zu einem Stand zurück kehren.

Ergänzung (für Windows-Benutzer): http://www.python-forum.de/topic-12200.html

mfg
Gerold

[Y0Gi]

Für die Arbeit mit Hg/Mercurial unter Windows empfehle ich Qct als grafisches Commit-Tool. Es soll ebenso mit anderen Betriebssystemen wie auch anderen SCM funktionieren. Da die Shell unter Windows natürlich kein Vergleich zu einer Unix-Shell ist (jetzt kommt mir nicht mit diesem PowerShell-Schrott aus Vista; Vista ist indiskutabel - aber das Thema gehört hier nicht her), ist mir diese grafische Alternative sehr willkommen.

Da mir das sofortige Aufzeigen von Diffdetails sehr gefällt, könnte ich Qct eigentlich auch mal testweise für SVN benutzen.

[Leonidas]

(jetzt kommt mir nicht mit diesem PowerShell-Schrott aus Vista; Vista ist indiskutabel - aber das Thema gehört hier nicht her)

Wer sagt denn, dass PowerShell nur auf Vista läuft?

Hey, was ist mit Bazaar? Ich nutze das seit über einem Jahr - es gibt oft Updates, es funktioniert gut und recht intuitiv und ist ebenso in Python geschrieben (als ob das ein Kriterium für SCMs wäre, aber egal).

Zur Frage des OP: Natürlich ist es sinnvoll New-Style-Klassen zu verwenden. Du musst nicht ihre zusätzlichen Features benutzen aber du kannst. Und ab Python 3.0 wird es keine Old-Style-Klassen mehr geben.

[poker]

Warum nicht SVN? Arbeite schon seit Jahren damit und habe keine Probs?
Hab mich nicht mit GIT, etc beschäftigt und daher eine kurze frage bevor ich meine Zeit dafür investiere: Was genau sind die Vorteile von GIT, Bazaar und Mercurial? Würde sich der umstieg lohnen und läuft das Migrieren der SVN-Repos nach $OTHER problemlos?

BTW: Pythons mitgeliefertes unittest würde ich nciht mehr empfehlen. Wenn dann nose oder py-test.
Ein guter vergleich:
http://agiletesting.blogspot.com/2005/0 ... ttest.html
http://agiletesting.blogspot.com/2005/0 ... ctest.html
http://agiletesting.blogspot.com/2005/0 ... -tool.html

@CrackPod
Hi, ich würde es erstmal auch so machen wie von veers vorgeschlagen. Das bietet sich immer an wenn man von einem Thema wenig Ahnung hat. Dabei kannst du dann schon viel bei lernen und design mistakes lokalisieren. Wenn du dann vom experimentier Stadium weg bist, anfangen das ganze sauber umzusetzen und wenn möglich versuchen ein 100%ige Unit test Abdeckung zu schreiben; Coverage kann dir dabei behilflich sein.

Unit test werden nicht nur für dich wichtig sein sondern auch für Leute die später deinem Projekt beiträten. Es lässt sich angenehmer Arbeiten, wenn man weiß das ein Test existiert der Modifikationen bestehender Komponenten auf Korrektheit verifiziert

[lutz.horn]

Was genau sind die Vorteile von GIT, Bazaar und Mercurial?

Ein wesentlicher Unterschied ist das Repository-Modell. Siehe z. B. http://en.wikipedia.org/wiki/Comparison ... l_software

Repository model describes the relationship between various copies of the source code repository. In a client-server model, users access a master repository via a client; typically, their local machines hold only a working copy of a project tree. Changes in one working copy must be committed to the master repository before they are propagated to other users. In a distributed model, repositories act as peers, and users typically have a local repository with version history available, in addition to their working copies.

Eine exterm kurze Einführung in das Konzeot von Mercurial findet sich unter http://www.selenic.com/mercurial/wiki/i ... gMercurial

[Leonidas]

Warum nicht SVN? Arbeite schon seit Jahren damit und habe keine Probs?
Hab mich nicht mit GIT, etc beschäftigt und daher eine kurze frage bevor ich meine Zeit dafür investiere: Was genau sind die Vorteile von GIT, Bazaar und Mercurial? Würde sich der umstieg lohnen und läuft das Migrieren der SVN-Repos nach $OTHER problemlos?

Es gibt mit Tailor ein Tool, dass Repositories migrieren kann - aber in wie gut das funktioniert kann ich nicht beurteilen.
Der Vorteil von den von dir angesprochenen Systeme ist, dass sie Verteilt funktionieren - es gibt also kein zentrales Repository und davon abgeleitete Checkouts sondern dezentrale Repositories, die sich jeder anlegen kann. Damit kann man beispielsweise ohne Internet Commits machen und diese dann mit anderen Entwicklern später auch synchronisieren. Die Server-Fähigkeiten erfordern im Gegensatz zu SVN über WebDAV kein spezielles Modul für den Webserver und die Synchronisation kann über ganz viele verschiedene Wege erfolgen (E-Mail, FTP, etc). Im Mercurial gibt es zum Beispiel die Möglichkeit, bestimmte Changesets in eine Datei zu packen und diese zu verschicken. Es gibt für alle drei eine Trac-Integration, nur ist beispielsweise die von Bazaar noch unfertig. Dafür kann Bazaar auch mit SVN-Branches arbeiten, wenn man so etwas braucht.

Ein unterschied ist auch die Entwicklung. Ich kann dir nicht sagen, wie es bei den anderen DVCS aussieht, aber von Bazaar gibt es grob jeden Monat eine neue Version mit Verbesserungen (oft wegen der Performance, denn Bazaar war Anfangs sehr langsam, vor allem wenn das Repository groß wurde). Aber wenn du mit SVN zufrieden bist - kannst du auch dabei bleiben.