Überblick über Projekt verloren, was nun?

[che]

Hallo!

Ich habe gerade mal knapp 2000 Zeilen Code geschrieben und habe schon keinen Überblick mehr über meine Operationen. Ich benutze IntelliJ IDEA und kann mir meine Operationen ("Structure") wie bei Eclipse anschauen, aber ich kann nicht mehr 100% meinen Gedankengang nachvollziehen als ich die Operationen schrieb. Ich habe eine Pause eingelegt und bin dabei die Kommentare etwas ausführlicher zu schreiben. Ich wollte euch fragen wie es euch gelingt einen Überblick über einen großen Projekt zu bekommen. Ich weiß, dass so etwas normalerweise Insiderwissen ist und dass man es selbst lernen muss, aber habt Erbearmen mit mir . Ich habe leider den Fehler zu Anfang gemacht und kein UML Diagramm erstellt, aber daraus bin ich jetzt schlau geworden...

 

[Craven]

Hallo!

Mein aktuelles Project hat ca 100000 Zeilen und ich hab keine Probleme mit dem Überblick und mit UML hab ich mich auch nicht beschäftigt.

Mein Rat:

1. Packe soviel wie möglich in eigene Klassen und Packages.
2. Gewöhn dir einen Programmaufbau an, den du immer einhältst.
3. Wenn die Grundform einer Software funktioniert, führe ich immer einen "Rewrite" durch, d. h. ich durchforste meine gesamte Programmstruktur, schaue, was sich vereinfachen, vererben oder in Methoden packen läßt.
4. Es gibt immer zwei Lösungen für ein Problem, eine ausführliche und eine kurze. Die ausführliche Lösung ist im Regelfall wesentlich besser lesbar.
5. Die wichtigste Regel Dokumentieren, Dokumentieren, Dokumentieren.
6. Die wichtigste Regel Dokumentieren, Dokumentieren, Dokumentieren.

Aus meiner Sicht bist Du in der Phase, in der du deine Software komplett überarbeiten mußt. Nimm dir die Zeit! Außerdem wächst man mit der Zeit. Als ich mit PHP vor x Jahren angefangen habe, war bei einem Programm mit 1000 Zeilen schluß, dann bin ich ausgestiegen. Nach über 3 Jahren Java kenn ich solche Probleme nicht mehr.

Man wächst mit seinen Aufgaben und viel Spaß beim Rewrite.

Craven

 

[che]

Ja, dass mit dem Rewrite sehe ich auch ein -bringt sehr viel. Wie aber machst du das mit dem Dokumentieren? Integrierst du die Kommentare im Code oder schreibst du eine externe Dokumentation, wo du deine Gedanken festhälst?

 

[Beni]

Ich behalte die Übersicht auch ohne UML oder andere Diagramme ganz einfach indem ich viele Kommentare schreibe. Etwa 30-40% meines Quellcodes ist reiner Kommentar (und zwar nicht "wie" etwas geschieht, sondern "was" geschieht!).

Das hat auch ein bisschen was mit Übung zu tun: irgendwann bist du soweit, dass du alles soweit in kleine, relativ unabhängige Module aufteilst, dass du die einzelnen Module verstehen kannst.

Die Übersicht "wiederzubekommen" ist hingegen schwerer... zur Not: 2000 Zeilen sind nicht viel, das kannst du auch noch ein zweites mal schreiben (und die Fehler vom ersten mal verwmeiden).

[Edit] Zu Dokumentation: es gibt ein wundervolles Tool namens javadoc: man schreibt die Kommentare im Code, und javadoc generiert daraus ein externes Dokument :wink:

 

[meez]

Integrierst du die Kommentare im Code oder schreibst du eine externe Dokumentation, wo du deine Gedanken festhälst?

Geanau dafür kannst du UML nahemen, um die Architektur und den Aufbau deiner Software festzuhalten...
Im Code selber dokumentier ich nur, wenn etwas ziemlich kompliziert ist, oder an dieser Stelle einfach nicht richtig reinpasst...oder sonstwie zu erwähnen ist...

 

[che]

Javadoc und UML, ein unschlagbares Team

 

[Craven]

beni hat geschreiben, daß bei ihm ca 30-40% seines Codes Dokumentation ist. So sieht es bei mir auch aus.

Wobei ich javadoc Kommentare nehme um Methoden zu beschreiben. Und dann noch jede Menge extra Kommentare, damit ich später weiß, was ich an welcher Stelle in meinem Programm mache.

 

[Ontos]

Moin Moin

*Java Doc
*Kommentare in den Code
*lesbar programmieren!
**öfters mal ein Refaktoring durchführen (1mal die Woche!!)
**Code nicht optimieren (DAS macht der Compiler nicht der Coder)
*externe Doku durch ein Wiki System das nebenbei läuft und in das alle Gedanken eingetragen werden => "Hacks" (wenn nicht zu verhindern) werden so für alle Mitarbeiter findbar und erkennbar
**Vorteile:
***automatische Versionskontrolle
***Suchfunktion
***Teamfähig
***einfache Bedienung die nicht viel Zeit frißt.
*Mein Leitspruch: MAKE IT SIMPLE!

Und zum ende das wichtigste...

Lernen durch SCHMERZEN!

cu Ontos

 

[che]

Danke Ontos, Schmerzen erfahre ich gerade, obwohl ich erst so ein kleines Projekt habe