Vorgehensweise fremden Quelltext verstehen

ProbeEtPylon

Mitglied
Hallo Forum,

Könnt ihr mir eine gute Vorgehensweise empfehlen, wenn man versucht, den Quelltext von fremdegeschriebenen Programmen zu verstehen?
Die Unmenge an verschiedensten Klassen und Dateien wirkt auf den ersten Blick erschlagend und ich frage mich, ob es diesbezüglich Tricks und Kniffe gibt.

LG,
ProbeEtPylon
 

Final_Striker

Top Contributor
Ich würde mir zuerst z.b. durch das Erstellen von Klassendiagrammen einen großen Überblick verschafen was und wie miteinander zusammenhängt.

Danach kann man anfangen sich die Klassen und ihre Methoden genauer anzuschauen.
 

Evil-Devil

Top Contributor
Am besten erstmal das Projekt als solches verstehen und kennenlernen. Denn dann begreift man meist auch die Zusammenhänge im Source schneller. Ist zumindest meine Erfahrung.
 

Gregorrr

Bekanntes Mitglied
Es gibt nicht die einzig glücklichmachende Methode, aber man kann es wohl einmal in seine eigene Psychologie-Aspekte kategorisieren und einmal, wenn du tatsächlich Änderungen am Code machen musst
1. Freuen, dass derjenige keinen Scala-Code benutzt hat ;)
2. Nicht versuchen, alles gleich gut verstehen zu wollen, sondern den Fokus auf den Bereich (Klasse/Methode) legen, die man untersuchen möchte, sofern man diese schon gefunden hat. Vieles hängt natürlich davon ab, wie gut derjenige vorher programmiert hat und kohärent alles abstrahiert hat, d.h. ob Klassen wirklich in sich stimmig sind und nicht zu viel mit anderen kommunizieren. => Versuchen auf einen Teil-Bereich zu fokussieren und alles andere erst einmal ausblenden und darauf vertrauen, dass die Klassen auch wirklich das machen, was sie sollen.

Eventuell:
3. Nicht dauernd über den schlechten Stil/Coding/API-Design Fehler fluchen, es ändert nichts. Einige "Java"-Programmierer haben eher einen C-Stil, andere haben wiederum einen guten OO-Stil, jedoch ändert es nichts, wenn es 100 Klassen gibt, die alle öffentliche Felder haben und dazu noch statisch sind und alle miteinander fröhlich auf direkte Felder zugreifen und womöglich verändern. Ist da zu viel Spaghetti-Code muss man entscheiden, ob es wirklich Sinn macht, oder nicht.

Falls du Änderungen machen willst:
4. Eventuell Test-Cases um den Code bauen. M.Feathers schreibt sinngemäß: jeglicher Code, der nicht in Test-Cases ist, ist automatisch legacy code.

Ansonsten, wenn du öfters mit legacy-code zu tun hast, empfiehlt sich das Buch: "Working Effectively with Legacy Code" von M. Feathers.
 

_ebm_

Mitglied
Ich habe es diesen Sommer gerade hinter mir. Viel Legacy-Code, mehrere in Skill und Herkunft total unterschiedliche Programmierer, kein gemeinsamer "Grund-Stil" (Benennung, Formatierung...) und aus 10 Jahren Firmengeschichte. Der erste Weg ist, sicherlich Test-Cases zu lesen. Gibt es sie nicht (genügend), hat man bestimmt kleinere Aufgaben, die man erledigen soll. Die sind oft recht lokal. Dabei lernt man sehr gut und schnell, wie der Code funktioniert. Ich finde übrigens durchaus, dass man über Code fluchen darf ;) Das ist besser, als runterschlucken. Eines sollte man aber nicht, alles wegwerfen und neu beginnen.... aber das ist ein anderes Thema...
 
E

emailundlos

Gast
Halt dich einfach an die code conventions das sollten deine Teammitglieder auch machen. Wenn sie das nicht machen, habe ich z.b. erlebt, bleibt die abreibt eben bei einem selber.
 
Zuletzt bearbeitet von einem Moderator:

_ebm_

Mitglied
Falsch verstanden. Der Legacy-Code ist schwer zu verstehen, weil er keinen einheitlichen Coding-Guidelines folgt. Es gibt leider kaum Teams die an größeren Projekten gemeinsam arbeiten, eher ein bis zwei Programmierer je Projekt und dafür viele davon ;) (Typisch Softwarehaus..)
 

Evil-Devil

Top Contributor
Oder man hat Legacy Code der auf an vielen Stellen mit c&p erstellt wurde und teilweise gar nicht mehr für einen Bereich benötigt wird. Sowas macht immer wieder Spaß.
 
E

emailundlos

Gast
Objekte anlegen und, aber alles automatisch. @_ebm_ verstanden hab ich schon was du geschrieben hattest. darauf genau kommt es nach meinung von meinen chef aber nicht an. jeder hält sich an etwas anderes.
 

Ähnliche Java Themen


Oben