Wie analysiert ihr Source Code / Tipps zum Verstehen von fremdem Code

[oppi]

Hallo zusammen !
Ich muss ein relativ großes Projekt(>50k Zeilen code) übernehmen, das eigtl. nur noch gepflegt werden muss. Jedoch Bug-Fixing oder evtl. Erweiterungen nicht ausgeschlossen.

Mein Problem ist nun, das die Doku relativ dürftig ist, eigetnlich nur aus JavaDoc besteht. Habt ihr Tipps wie ich am besten drangehe um den Code zu analysiere, bzw meine eigene "Doku" zu erstellen ?
Bin dabei mich durch jede Klasse zu arbeiten mit Ablaufplänen, kurzen Beschreibungen etc, was jedoch extrem zeitintensiv ist

Bin für jede Anregung/Vorschlag dankbar

lg

 

[Atze]

darum dir jede (wichtige) klasse anzugucken, da kommst du wohl nicht drum rum. aber jede klasse mit javadocs versehen - dast ist doch toll! viele projekte haben nichtmal das!!!! sei froh!

und alles musst du dir zuerst wohl nicht angucken, bei einem so großen projekt werden sicher einige utilitiy-klasse dabei sein, wo du nie dran musst, oder die schon so ausgereift und fertig sind, dass sie dich nicht wirklich vom interna her interessieren müssen.

wenn das projekt n core hat wo oft dran gearbeitet wird, würd ich mir den mit ein paar testobjekten mal anschauen und durchdebuggen um zu sehen, was da wo und wann passiert. irgendwann wird sich herauskristallisieren, wo das meiste passiert und wo die großen baustellen sind. wenn das dann nicht intuitiv genug läuft, würd ich mir da zuerst notizen machen. dann immer da wo du grad dran bist, irgendwann hast du deine eigen doku!

 

[Ullenboom]

Das ist ein hartes Problem. Ich würde versuchen erst mal die Pakete zu verstehen und die Schichten zu entdecken. Große Projekte haben in der Regel ein Modell nach dem Prinzip: Presentation Tier, Business/Service-Layer, Backend. Dann kann man z.B. mit UML-Tools versuchen ein Reengineering zu starten, dass man die Abhängigkeiten von Paketen erkennen kann. Und: Wenn man eine Datei aufmacht und die enthält keine Doku, dann JavaDoc reinschreiben mit dem was man verstanden hat. Dann sind auch JUnit-Testfälle hilfreich. Wenn welche da sind, sieht man isoliert (im Idealfall) die Funktionsweise. Natürlich verraten auch Jar-Archive was. Ein weiterer Tipp: Jar-Archive aus dem Klassenpfad nehmen --> an den Compilerfehlern merkt man dann, wo die Libs gebraucht werden.

Grüße

Christian

 

[kama]

Hallo,
wenn ich die Möglichkeit hätte würde ich mir Tests schreiben, so nicht schon vorhanden...damit lernt man Code am besten kennen...

Gerade wg. Bug Fixing etc. und eine eigene Doku schreiben ist auch nicht von Pappe...

Gruß
Karl Heinz Marbaise

 

[VfL_Freak]

Moin,

Ich muss ein relativ großes Projekt(>50k Zeilen code) übernehmen, das eigtl. nur noch gepflegt werden muss. Jedoch Bug-Fixing oder evtl. Erweiterungen nicht ausgeschlossen.

Mein Problem ist nun, das die Doku relativ dürftig ist, eigetnlich nur aus JavaDoc besteht. Habt ihr Tipps wie ich am besten drangehe um den Code zu analysiere, bzw meine eigene "Doku" zu erstellen ?
Bin dabei mich durch jede Klasse zu arbeiten mit Ablaufplänen, kurzen Beschreibungen etc, was jedoch extrem zeitintensiv ist

oh ja, das Problem kenne ich gut - ich musste hier mehrere ähnlich große Projekte (Java und C++) übernehmen, die allesamt fast komplett undokumentiert waren ... ;(

Im Zweifel hilft Dir da für eine intensive Codeanalyse IMHO nur der Debugger weiter :autsch:

Gruß
Klaus