@Käptn Haddock:
Dafür versuche ich mich zur Zeit in der Anwendung von Tests, hab da aber noch so meine Schwierigkeiten.
Was meinst Du mit "Anwendung von Tests"?
@veers:
Ich versuche dabei mehr über Dienstleistungen nach zu denken als über Klassen oder Funktionen.
Meinst Du mit Dienstleistungen die Funktionalität des Programmes? Denn genau da liegt oft mein Problem, dass ich wohl eine ziemlich genaue Vorstellung dessen habe, was das Programm leisten soll, allerdings noch keinen verwertbaren Überblick darüber, welchen Einfluß Funktion A auf Funktion B einmal haben wird oder einmal haben muss. Konkret: Ich hatte in meinem Kalenderprogramm eine Klasse Coords() und eine Klasse View(). Coords() war dafür zuständig, die Koordinaten für die Tage und die Termine einer Kalenderansicht zu berechnen und bei Bedarf (z. B. ein Klick auf einen Termin) wieder auszuspucken. View() wiederum erhielt von Coords() die Koordinaten und zeichnete die Kalenderansicht. Irgendwann legte ich beide Klassen zusammen, da das ermitteln der Koordinaten und das Zeichnen der Ansicht so nah beieinander liegen, dass es mir unsinnig erschien, diese so eng miteinander verwobenen Funktionen in verschiedene Klassen zu deponieren. Inzwischen habe ich also dafür nur noch die Klasse View(). Diese Klasse wiederum muss momentan wieder "umgebaut" werden, da ich sie nicht nur für die Kalenderansicht, sondern auch für den Kalenderpicker verwenden möchte, da der wxPython-eigene datepicker nicht so dolle ist.
Und so weiter, und so weiter... Denkst Du nicht, dass eine gründlichere Planung der Programmstruktur wichtiger ist, als über die Dienstleistungen nachzudenken, die sich doch in einen gut aufgebauten Code viel einfacher einbauen lassen, als schlecht durchdachten Code ständig umwerfen zu müssen?
Oder reden wir von zwei unterschiedlichen Dingen?
@Pekh:
Einfach mal nach "Object Process Methodology" googeln.
Werde ich machen, danke für den Tipp, klingt interessant.
Mein Fehler ist, daß ich immer viel zu lange nach der elegantesten Lösung suche.
Ich weigere mich, darüber nachzudenken, wieviele Stunden ich damit schon verbummelt habe...
@gerold:
...dann nehme ich auch FreeMind um damit Knoten in meinem Hirn zu lösen.
Wie oft schon hab' ich in meinen VIM gestarrt und hatte das Gefühl, mir explodiert gleich der Kopf, weil ich Zusammenhänge nicht mehr übereinander gebracht habe. Ohne xMind wäre ich schon längst gescheitert...
So wie Du Deine Vorgehensweise beschreibst stelle ich mir das auch in etwa vor, das von Dir erwähnte Trac Project habe ich mir installiert, werde ich mir die Tage mal zu Gemüte führen. Ich muss zu meiner Schande gestehen, dass ich mich mit Versions-Systemen noch überhaupt nicht auseinandergesetzt habe. Irgendwie ist mir das Thema zu groß... Aber selbst für einen Hobbyprogrammierer kann das wohl sehr hilfreich sein.
Das hat den Vorteil, dass ich im Laufe der Entwicklung am Morgen eines Tages, wenn ich noch nicht ganz fit bin, nicht immer nachdenken muss, mit was ich an diesem Tag beginne.
Wenigstens dafür sind meine kläglichen Notizen nütze: Zu wissen, wo es weitergeht!
@Leonidas:
Generell gehe ich oft nach dem Vorgehen "the simplest thing that could possibly work" vor auch wenn das bedeutet dass ich manchmal Teile neuschreiben muss. Aber dann weiß ich wenigstens was die wirklichen Anforderungen sind und muss nicht mit irgendwelchen Phantomanforderungen rechnen die irgendwann vielleicht, vielleicht nicht dazu kommen aber dafür den Code komplex machen.
Nun ja, zwischen schwarz und weiß liegen die vielen Grautöne... Ich geb' Dir natürlich Recht und stehe auch oft in der Gefahr, über Eventualitäten nachzudenken, die noch gar nicht eingetreten sind. Andererseits denke ich, dass es schon auch Sinn machen kann, das eine oder andere "Leerrohr" einzuziehen. Klar, natürlich nur, wenn man davon ausgehen kann, dass man später auch Kabel reinlegt.
Jedenfalls schon mal "Danke!" an Euch alle. Bin gespannt, ob noch mehr kommt...
Liebe Grüße
mutetella
