Von der Idee zum fertigen Programm

[kevind]

Hallo zusammen,

ich wollte mal fragen ob es nur mir so geht oder andere auch mit ähnlichen "Probleme" kämpfen.

Ich schreibe gerade ein Text Adventure und komme immer mal wieder zum punkt wo ich den Codeteile umbaue weil gewisse Dinge doch nicht so funktionieren oder es sich herausstellt das es auf diese Weise doch zum kompliziert / unübersichtlich wird.

Verwendet ihr Tools wie Mindmaps oder ähnliches um sich das auch besser visuell vorzustellen ? Oder ist es einfach die Erfahrung die es ausmacht?

Gruss, Kev

[BlackJack]

@kevind: Ich dokumentiere Sachen die unübersichtlich sind. Also zum Beispiel eine Sicht aus der „Vogelperspektive” wozu welches Modul gut ist, und wie die einzelnen Klassen/Datenstrukturen miteinander verbunden sind. Für Klassen/Objektbeziehungen die für einen Text zu kompliziert sind, kommt auch schon mal ein kleines UML-Diagramm dazu. Wobei da (mir) wichtig ist: Man muss nicht alles was man in einem UML-Diagramm einzeichnen kann, auch wirklich drin haben. Nur so viel, dass der wichtige Punkt rüber kommt, den man damit verdeutlichen wollte.

[mutetella]

Mir hilft es auch sehr, so zeitnah wie nur möglich zu dokumentieren. Während ich das, was eine Funktion oder Klasse tut bzw. wie sie es tut, versuche so zu beschreiben, dass es andere verstehen, bemerke ich oft, dass meine Herangehensweise ungeschickt oder sogar falsch ist.

mutetella

[kevind]

Das heisst ihr Dokumentiert noch ausserhalb des Editors, bzw. euch reichen Kommentare nicht aus ?

[BlackJack]

@kevind: Das kommt drauf an. Wenn es zu umfangreich für DocStrings wird, nehme ich Sphinx zur Hand. Das Problem sind ja oft nicht direkt die Klassen oder Methoden, selbst wenn die gut dokumentiert sind, sondern das man den Überblick behalten muss, wie das alles zusammen spielt. Und wenn das zu viel für den modulweiten DocString wird, dann muss man ja irgendwo hin ausweichen. Da können dann auch zusätzliche Informationen untergebracht werden, wie Abhängigkeiten, eine Anleitung wie man das Programm/System aufsetzt, Changelog, Todo, Roadmap, und so weiter.

[mutetella]

@kevind
Ich mache beides. Den Code selbst dokumentiere ich über docstrings und versuche mich dabei kurz & knapp zu halten aber dennoch nichts, das die zu dokumentierende Funktion tut oder eine Klasse umfasst, wegzulassen. Gelingt das mit dem "kurz & knapp" nicht, beginnen sich in mir schon die ersten Zweifel ob der richtigen Herangehensweise zu rühren...

Wenn ich beginne, ein neues Feature zu implementieren, beginne ich gerne damit, zuerst die Benutzerdokumentation dafür zu schreiben. Dadurch mache ich mir selber erstmal klar, wie etwas am Ende funktionieren soll, d. h. was der Nutzer wie tun muss um zu einem bestimmten Ergebnis zu kommen. Ich hab' einfach schon zu oft erfahren müssen, dass etwa eine Funktion Rückgabewerte lieferte, die ich so eigentlich nicht benötigte...
Wobei das jetzt bei Deinem Spiel sicher etwas anderst verlaufen wird, als es bei meinem Kalender Sinn macht...

mutetella

[mutetella]

... hab' ich noch vergessen: Was mir auch sehr hilft, den Überblick zu bewahren und auch den Kopf frei zu halten ist Trac. Dort habe ich alles an einem Ort:
Meinen Code in Form eines VCS.
Ein Wiki zur Dokumentation und als Platz, an dem ich mehr oder weniger thematisch geordnet interessante Informationen und/oder Links, die für mein Projekt eventuell von nutzen sein könnten unterbringe.
Ein Ticketsystem, das ich dafür nutze, Ideen für neue Feature oder Herangehensweisen, Fehler, die mir aufgefallen sind, TODO's und so weiter zu notieren. Einmal aufgeschrieben muss ich keine Angst mehr haben, etwas zu vergessen und ich verzettel mich auch nicht mehr, weil ich etwas gleich machen wollte, damit irgendeine Idee nicht verloren geht...
Wenn man seine Tickets dann noch mit einer Roadmap verknüpft tut man sich schon etwas leichter, diszipliniert und strukturiert einen Punkt nach dem anderen abzuarbeiten und nicht wie es gerade so kommt ins Blaue hinein zu programmieren.

mutetella