In ein fremdes Projekt einarbeiten
-
Wenns um Fehlerbehebung geht, dann mach ich das immer so, dass ich den Fehler vom Auslöser weg verfolge... Beispiel:
Wenn ich beim Öffnen einer Datei, das durch einen Buttonklick ausgelöst wurde einen Fehler suche, dann geh ich von diesem "OnClick" ereignis aus und verfolge jeden Funktionsaufruf... (überall Step-in quasi)
Wenns ums Erweitern geht, dann musst du wohl wirklich erst einen Überblick über die Klassen verschaffen und die Archithektur der Anwendung studieren.
-junix
-
Ziemlich unkommentiert das ganze
Mit anderen Worten: Ich bin gar nicht schuld, dass ich das Programm nicht versteh, sondern meine Vorgänger
-
Original erstellt von Winzler:
Ziemlich unkommentiert das ganze
Mit anderen Worten: Ich bin gar nicht schuld, dass ich das Programm nicht versteh, sondern meine Vorgängerjo, vermutlich.
je nach programmierfähigkeit kann es aber auch code sein, der fast keine kommentare braucht. dann wäre es deine schuld. ist aber recht unwahrscheinlich, sowas zu begegnen.
gerade dann, wenns ein langsam gewachsenes projekt mit vielen anbauten ist, kannstes oft vergessen.
-
...gerade dann, wenns ein langsam gewachsenes projekt mit vielen anbauten ist, kannstes oft vergessen.
...und genau das ist es. Angefangen von einer externen Firma, dann von einem Werksstudenten weitergemacht, dann von einem anderen Studenten... usw.
Naja, muss ich halt versuchen, das beste daraus zu machen.
-
Tja, wenn der Vorgänger nicht greifbar ist, bleibt dir nix anderes als dich mit viel initialaufwand in das Projekt einzuarbeiten. Aber als Tip: Tu dir selber den Gefallen und kommentier den Code dabei gleich auch noch und halte deine Erkenntnisse irgendwo (nicht in deinem Kopf! in schriftlicher Form!) fest. Sonst fällts wieder auf dich zurück (o;
-junix
-
Ich find nützlich große zusammenhängende Blöcke auszudrucken und an die Wand zu kleben. Da kann man manchmal besser den überblick behalten und schauen wie was zusammenhängt als wenn man immer scrollen muss.
-
Jo, das ist wirklich praktisch.. oder einfach mal anfangen die erkannten Zusammenhänge zwischen Objekten und Klassen aufzumalen, muss nichts schönes sein, nur zweckdienlich... Dann bekommt mit der Zeit im wahrsten Sinne des Wortes eine Archithektur zu Gesicht (o:
-junix
-
doxygen (oder ähnliches) ist da dein Freund.
Liefert schonmal einen wunderbaren Überlick über die Zusammenhänge zwischen den Klassen.
-
Guter Code braucht keine Dokumentation/Kommentare!
Ich hab mich bis jetzt zweimal in sehr große Projekte einarbeiten müssen, die eigentlich überhaupt nicht kommentiert waren. Eigentlich gehe ich immer so vor: ich schaue mir erstmal die Klassennamen und Vererbungen an, daran kann man immer schon mal erkennen, wofür welche Klasse zuständig ist. Wenn man das daran nicht erkennen kann, dann ist der Code sch**** und der Ur-Entwickler gehört gesteinigt.
Eine Klasse für ein Fenster muß doch mind. von einer Klasse abgeleitet sein, die irgendwie "Window" o.ä. im Namen trägt. Und selbst müsste die Klasse doch zumindest am Ende Win o.ä. tragen. Das erleichtert doch schon mal ungemein den Code zu überblicken.
Genau das gleiche trifft auf Methoden zu.
Nun, wenn mir gesagt wird, da und da möchte der Kunde ein neues Feature haben, dann suche ich erstmal die passende Klasse raus in der ich mich erstmal umschaue.
Auch hilft es ungemein, einfach mal im Code zu debuggen. Z.B. im Konstruktor einer Klasse die einen interessiert, nen Breakpoint setzen. Und dann einfach mal debuggen, und schauen wer wo diese Klasse instanziert. Und wie es denn so weiter geht. Mit debuggen kann man seeehr viel über das Projekt lernen, obwohl man keinen betsimmten Bug sucht.
[ Dieser Beitrag wurde am 28.06.2003 um 15:52 Uhr von Artchi editiert. ]
-
Also ich geh immer direkt von der main Funktion aus und schau mir dann die aufgerufenen Funktionen/Objekte an und versuch mich so durch zu arbeiten. Mit dem Debugger einfach mal den Programmablauf zu betrachten ist auch oft sehr nützlich.
doxygen (oder ähnliches) ist da dein Freund.
Doxygen ist toll, aber nützt einem leider nichts, wenn der vorherige Programmierer es nicht benutzt hat
und doxygen schützt auch nicht vor dummen oder fehlenden Kommentaren.