Organisation von umfangreicheren Python Projekten

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
jimKnopf
User
Beiträge: 11
Registriert: Donnerstag 4. Dezember 2008, 08:52

Hallo Allerseits!

Ich bin gerade dabei ein etwas umfangreicheres Projekt zu basteln. Umfangreicher heißt, das es inzwischen doch über 500 Zeilen Code geht, und das ist immernoch nicht das Ende, da noch einige Features fehlen, einige sachen noch etwas zu spezifisch zum testen gelöst sind, etc. - egal.

Jedenfalls ist mein Problem ist, das es mein erstes Projekt von dieser Diemension ist. Ich merke gerade das es so langsam schwierig wird die Übersicht zu behalten.
Die einzelnen Dateien sind zwar meist so prgrammiert, das ich schnell wieder weiß, was ich gemacht habe, aber ich suche etwas um den Überblick zu behalten.
Angefangen habe ich auch schon das Projekt in Module zu zerteilen. Als IDE benutze ich im Moment Eclipse, das hilft mir schon mal recht ordentlich weiter, aber so als Weisheits letzter Schluss empfinde ich es nicht. Ja und ich brauch auch nichts um ein Team zu steuern, ich arbeite zumindest daran alleine.

Daher hier meine Fragen: Kennt jemand ein nicht zu umfangreiches Buch/Tutorial wie man solche wachsenden Projekte unter Kontrolle behält?
Welche Tipps und Tricks habt ihr so drauf um sowas zu überblicken?
Macht es sinn mit Soetwas wie UML oderso das Programm abzubilden? Bisher hab ich nur Skizzen, was welches Object mit wem interagiert, Quasi ablaufdiagramme.

Tja, noch habe ich keine konkreten schwierigkeiten, ich will halt nur verhindern, dass ich welche bekomme und hoffe das hier der eine oder andere erfahrene Programmierer Tipps für mich hat :)

Schon mal besten Dank für Vorschläge und Ideen,
Jim
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

Hi,

also 500 Zeilen Code ist jetzt nicht soooooo umfangreich...

Aber sonst:
* Benutze, auch wenn du alleine arbeitest, eine Versionverwaltung,
* Dokumentiere, schreibe Docstrings, etc.,
* organisiere deinen Code nach dem MVC-Prinzip,
* überlege dir *vor* der ersten Zeile Code die Struktur,
* lagere in Module aus was geht,
* nutze wo es geht bereits verfügbare Module (Don't reinvent the Wheel)
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

jimKnopf hat geschrieben: Macht es sinn mit Soetwas wie UML oderso das Programm abzubilden? Bisher hab ich nur Skizzen, was welches Object mit wem interagiert, Quasi ablaufdiagramme.
Ein ganz klares Nein. Mehr als diese Skizzen kann UML auch nicht bieten, zumal es ein recht enges Korsett schnuert, das auf C++/Java abgestimmt ist.

Es gibt leider keine Patentrezepte fuer das Problem. Also beschreib am besten deinen bisherigen Aufbau und das Problem das du loesen willst.
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

cofi hat geschrieben:Ein ganz klares Nein.
Also ich finde UML (wenn man es nicht all zu Dogmatisch sieht) schon sehr praktisch. Es hilft doch, die Übersicht zu bewahren. Aber das ist bestimmt auch Gewohnheits- und Geschmackssache.
jimKnopf
User
Beiträge: 11
Registriert: Donnerstag 4. Dezember 2008, 08:52

.robert hat geschrieben: also 500 Zeilen Code ist jetzt nicht soooooo umfangreich...
Ich weiß, aber es ist ja auch noch am Wachsen und das war jetzt nur so eine grobe Schätzung
.robert hat geschrieben: * organisiere deinen Code nach dem MVC-Prinzip,
* überlege dir *vor* der ersten Zeile Code die Struktur,
Zuspät! :lol:
Naja ist halt aus einem kleinen Skript gewachsen.

MVC, werd ich mir mal genauer anschauen, aber auf den ersten Blick sah es so aus, als käme es aus dem Bereich der Webentwicklung, das ist jetzt nicht ganz mein Bereich. :)

Also im Prinzip geht es darum die Verarbeitung von Simulationsdaten zu automatisieren und dann die ergebnisse automatisch in Reports und ein Wiki zu schreiben. Ich werde mal nachher etwas genauer versuchen das ganze zu beschreiben. Das Problem ist wohl unter anderem, das es einfach so gewachsen ist und nicht gesteuert wurde. Und wohl auch nicht ganz praktisch ist, das ich kein Informatiker, nichtmal sowas in der Art bin :)

Schon mal besten Dank für die Anregungen, freue mich über weitere Ideen und Kommentare

Grüße
Jim
lunar

Das kommt darauf an, wie man UML nutzt. Als Modellierungssprache für grobe Zusammenhänge zwischen verschiedenen Komponenten ist diese Sprache auch für Python sinnvoll, weil solche Modelle noch sehr weit von einer konkreten Sprache entfernt sind. Bei 500 Zeilen aber braucht es ein solches Modell nicht.

UML-Klassendiagramme aber sind für Python unbrauchbar, da solche starren Modelle die Dynamik der Sprache Python nur unzureichend abbilden. UML zu nutzen, ist auf dieser Ebene zwar immer noch möglich, aber unschön. Der „Java-Weg“, aus UML-Diagrammen Quelltext zu generieren, und anschließend nur noch die Implementierung zu stricken, ist in Python allerdings nie sinnvoll. Wenn überhaupt, dann nutzen allenfalls Klassendiagramme, die aus Python-Quelltext generiert wurden, um sich einen Überblick zu verschaffen.

Was das Dogma "Struktur zuerst" angeht, so habe ich auch meine Zweifel. Eine von vorne herein erdachte Struktur passt bei der anschließend Implementierung oftmals doch nicht so gut wie gedacht. Man sollte nicht nur denken, sondern auch so früh als möglich implementieren, da man die Tauglichkeit der Struktur bzw. des Modells nur durch die Implementierung prüfen kann. Im Zweifelsfall würde ich lieber erst mal einen Prototypen entwickeln, und diesen anschließend durch Refactoring in Form bringen.

In jedem Fall aber muss man so früh als möglich auf Struktur achten.

Für 500 Zeilen aber gleich „Ablaufdiagramme“ zu zeichnen, ist schon ziemlich übertrieben. Selbst bei 1000 Zeilen sollte man die Abläufe innerhalb des eigenen Quelltexts aus dem Kopf kennen. Benötigt man schon bei so kleinen Programmen Diagramme zur Übersicht, ist das eher ein Zeichen dafür, dass es bereits dem Quelltext an Übersicht und Struktur mangelt.
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Als Buchtipp zu deinem Problem kann ich dir "Expert Python Programming" von Tarek Ziadé empfehlen. In diesem Buch wird u.a. auf den gesamten Lifecycle eines Python-Softwareprojektes eingegangen.

BTW: Was stört dich an Eclipse? Du nutzt schon das Python-Plugin "Pydev"?
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher

http://ms4py.org/
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Wenn man UML braucht um die Übersicht über ein Projekt zu bewahren hat man was falsch gemacht.
Benutzeravatar
Käptn Haddock
User
Beiträge: 169
Registriert: Freitag 24. März 2006, 14:27

IMHO ist es das wichtigste, sich vorher Gedanken zu machen, was die Software leisten soll und muß. Daraus lässt sich eine erste Struktur ableiten, die man auch mit UML skizzieren kann. Daraus werden auch schon die gröbsten Problemstellen sichtbar, die man dann gezielt mit kleinen Prototypen angehen kann um das jeweilige Thema zu erforschen. Wichtig ist, das man immer in der Lage sein sollte, seine Struktur auch ändern zu können.
Danach kann man eine erste Version oder Prototypen implementieren, und sieht weitere Problemstellen... usw. Spätestens jetzt ist auch UML nicht mehr sinnvoll.

So versuche ich es zumindest zu machen (wenn man mich lässt ;)). Vorteile: Man hat immer ein bisschen was zu coden und zu experimentieren und kommt doch ganz gut voran. Nachteil: Man braucht eine gute Übersicht und Selbstdisziplin, sich an die eigenen Abläufe zu halten. Und sollte viel dokumentieren. Soll man aber sowieso ;) Ein gutes VCS ist natürlich auch ein MustHave, zur Zeit probiere ich da mercurial als Ersatz für subversion aus.
Und man soll sich von seinen Java-Kollegen nicht ins Bockshorn jagen lassen ;)

Gruß Uwe

EDIT: Achja, und man soll sich nicht in Optimierungen verlieren. Wichtig ist ertmal ein funktionsfähiges Stück SW...
---------------------------------
have a lot of fun!
lunar

@DasIch: Nicht alle Entwickler sind so gut wie Du, dass sie die Übersicht über ein Projekt von mehreren Millionen Zeilen bewahren, ohne Hilfsmittel in Form von Dokumentation oder Diagrammen heranzuziehen.

Ferner merke: UML ist weitaus mehr als Klassendiagramme (deren Nutzen in der Tat eher beschränkt ist).
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

lunar hat geschrieben:@DasIch: Nicht alle Entwickler sind so gut wie Du, dass sie die Übersicht über ein Projekt von mehreren Millionen Zeilen bewahren, ohne Hilfsmittel in Form von Dokumentation oder Diagrammen heranzuziehen.
Man muss nicht jedes Detail kennen, man muss bestimmte Dinge noch nichtmal überhaupt kennen aber man sollte über die grundlegenden Dinge die Übersicht bewahren können, so dass ein kurzer Blick in die Dokumentation ausreicht.
lunar

Tja, und da sind Diagramme eben ungemein hilfreich …
.robert
User
Beiträge: 274
Registriert: Mittwoch 25. April 2007, 17:59

DasIch hat geschrieben: so dass ein kurzer Blick in die Dokumentation ausreicht.
Dokumentation kann ja auch Diagrammen beinhalten ;)

Diagramme, und da vor allem Standardisierte, helfen ungemein, um sich im Team zu verständigen. Natürlich kann man das auch alles rein Textlich machen, aber bei einem Meeting ist ein Diagramm eben doch schneller an die Tafel gemalt - und alle wissen was gemeint ist, wenn man einen Standard einhält.

Der Threadstarter arbeitet alleine, und da bleibt es natürlich ihm überlassen, wie er die Anforderungen an seine Software spezifiziert. Ich finde Diagramme als Gedankenstützen und kleine Skizzen ungemein hilfreich. Gerade wenn das Projekt größer wird.
Pekh
User
Beiträge: 482
Registriert: Donnerstag 22. Mai 2008, 09:09

Es gibt da zwei Komponenten:

Zunächst den Überblick während der Entwicklung an sich bewahren. Bei einer halbwegs sauberen Struktur sollte das auch bei großen Projekten nicht das Thema sein. Man steckt halt in der Sache drin und weiß wo was und zumindest ansatzweise auch wie es gemacht wird.

Die andere Seite ist: Es wird der Moment kommen, in dem man sich, nach längerer Abstinenz, wieder mit dem Projekt auseinandersetzen muß. Sei es, daß ein Fehler aufgetreten ist, oder irgendwelche Anpassungen / Erweiterungen vorgenommen werden sollen. Ein gut strukturierter und kommentierter Code ist hier natürlich unschätzbar wertvoll. Auch Unittests sollte man haben, da man sonst schnell mal mehr kaputtändert als einem lieb ist. Um den Wiedereinstieg in das Projekt aber zu beschleunigen, sollte schon ein Minimum an externer Dokumentation vorhanden ist. Zumindest eine Skizze, welche Komponenten es gibt, in welchem Zusammenhang sie stehen und was ihre Aufgaben sind, sollte schon sein.

Auf der anderen Seite muß man auch immer bedenken: Je mehr Doku man hat, um so mehr Zeit muß man damit verbringen, sie auf dem neusten Stand zu halten. Macht natürlich keiner. Man könnte also auch sagen: Je mehr Doku, desto weniger aktuell ist sie. Gerade Ablaufdiagramme veralten wahnsinnig schnell. Abläufe kann man aus sauberem Code mit sinnvollen Schnittstellen aber auch gut ablesen, insofern mache ich mir die Mühe, derartige Diagramme zu pinseln schon gar nicht mehr.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Pekh hat geschrieben:Gerade Ablaufdiagramme veralten wahnsinnig schnell. Abläufe kann man aus sauberem Code mit sinnvollen Schnittstellen aber auch gut ablesen, insofern mache ich mir die Mühe, derartige Diagramme zu pinseln schon gar nicht mehr.
Ich muss an der Uni grad nen Projekt aufarbeiten, welches unserer einstiger Kernprogrammierer entwickelt hat. Da wäre ich heilfroh über einige Ablaufdiagramme gewesen! Nur Schnittstellen helfen bei komplexen Netzwerkkommunikationen, Threads und heftigen Callback-Strukturen nicht wirklich...

Ein wirklicher Referenzprozess für das Organisieren eines Softwareprojektes gibt es aber sicherlich nicht. Dafür sind diese einfach zu unterschiedlich bezüglich vieler Dimensionen.
Antworten