# Vorgehensweise fremden Quelltext verstehen



## ProbeEtPylon (3. Dez 2011)

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 (3. Dez 2011)

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 (6. Dez 2011)

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 (6. Dez 2011)

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.


----------



## ProbeEtPylon (6. Dez 2011)

Danke euch


----------



## _ebm_ (7. Dez 2011)

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...


----------



## emailundlos (7. Dez 2011)

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.


----------



## _ebm_ (7. Dez 2011)

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 (7. Dez 2011)

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ß.


----------



## bronks (7. Dez 2011)

> ... Test-Cases  ...


Könntet Ihr mir bitte scheiben, was Ihr unter "Test-Cases" versteht? Testfälle in Textform zur manuellen Durchführung?


----------



## Andgalf (7. Dez 2011)

bronks hat gesagt.:


> Könntet Ihr mir bitte scheiben, was Ihr unter "Test-Cases" versteht? Testfälle in Textform zur manuellen Durchführung?



Nein eher in Form von automatisierten Unit bzw. Integrationstests


----------



## emailundlos (7. Dez 2011)

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.


----------

