Software zum Visualisieren/Analysieren von Fremdcode

Thomas W. schrieb:
> Enterprise Architekt vielleicht ?

Das hab ich sogar hier. Benutz ich eigenlich wenig bis gar nicht, nur 
als UML tool ab und zu. Ich weiss das es ein ziemlich umfangreiches 
Paket ist, aber ich hab mich da noch nicht mit auseinandergesetzt. Hast 
du vielleicht ein bisschen Starthilfe bezueglich deines Tips? Ich wusste 
nichtmal das man mit EA code-Dateien einlesen kann

> Oder mit Eclipse und die Blöcke wegklappen (folding).
Ja, das ist was ich jetzt mache. Bei gut strukturierter Software hilft 
das ganz gut, wenn aber die meisten Funktionen nur wieder andere anrufen 
ohne selber was zu machen wirds schnell unuebersichtlich. Auch toll wenn 
jemand angefangen hat "Vererbung" in C zu machen ohne das irgendwo zu 
dokumentieren (erstes Element in einem Struct als "Parent Class" 
benutzen).

http://www.doxygen.org/

Damit kann man auch Code, der ohne spezielle Doxygen-Kommentare 
vorliegt, ganz OKen Überblick über die Programmstruktur bekommen.

enginerd schrieb:
> http://www.doxygen.org/
>
> Damit kann man auch Code, der ohne spezielle Doxygen-Kommentare
> vorliegt, ganz OKen Überblick über die Programmstruktur bekommen.

Hehe, das liegt so vor der Hand das ich da gar nicht dran gedacht hab. 
Danke dir

Ist das eine Software, die euer Vertrieb mit den Kunden ausgehandelt 
hatten?

Habe die Erfahrung gemacht, bei so etwas muss man die Sache ganz anders 
anpacken. Die Meetingprotokolle und Emails durcharbeiten. Erst mal 
heraus finden, was das System überhaupt machen soll.

Wenn du den Programmcode durcharbeitest stolperst du über 2 Probleme.
Du glaubst, du hättest das Programm nicht verstanden, weil dir deine 
Vermutungen unsinnig erscheinen.
Und du wendest viel zu viel Zeit für Details von Komponenten auf, die du 
sowieso komplett ersetzen musst.

Noch ein Kommentar schrieb:
> Ist das eine Software, die euer Vertrieb mit den Kunden ausgehandelt
> hatten?
Wir uebernehmen fuer einen Kunden ein bereits entwickeltes Produkt. Die 
Firma die das damals fuer den Kunden gemacht hat war gut in HW, aber 
relativ unerfahren in SW, vor allem embedded Linux. Was da damals 
ausgearbeitet wurde hat jahrelang funktioniert und gereicht, aber jetzt 
muss ein update her, und die Firma hat aus sich selber angegeben das sie 
sich nicht als kompetent genug sieht um das zu tun - embedded linux ist 
eben nicht deren Ding. So ist das ganze bei uns gekommen, und die Firma 
von der wir es uebernehmen hilft auch gern mit. Allerdings weiss das 
eigentlich keiner mehr genau was da vor 6 Jahren so die Gedankengaenge 
waren. Und so sieht der Code uebrigens auch aus.
Also hier ist nur guter Wille im Spiel von allen Seiten, das moechte ich 
betonen.

> Habe die Erfahrung gemacht, bei so etwas muss man die Sache ganz anders
> anpacken. Die Meetingprotokolle und Emails durcharbeiten. Erst mal
> heraus finden, was das System überhaupt machen soll.
In der Basis weiss ich das, zum Glueck ist es nicht uebermaessig 
komplex. Aber wenn da drivers via I2C oder SPI arbeiten, dann erwartet 
man im ersten Moment natuerlich nicht, dass der SPI handler zwar da ist, 
aber nicht benutzt wird, weil im I2C handler irgendwie mit ner extra 
Abfrage auf einmal nach SPI verwiesen wird. Ich hab zwar eine Ahnung 
warum derjenige das damals gemacht hat, aber genau wissen tuts niemand

> Wenn du den Programmcode durcharbeitest stolperst du über 2 Probleme.
> Du glaubst, du hättest das Programm nicht verstanden, weil dir deine
> Vermutungen unsinnig erscheinen.
> Und du wendest viel zu viel Zeit für Details von Komponenten auf, die du
> sowieso komplett ersetzen musst.

Das stimmt - es ist aber schwierig zu verkaufen, denn das system so wie 
es ist funktioniert ja. Das Argument "manches/vieles/alles muss neu" ist 
teuer und muss schon unterbaut werden - auch daher eben die 
Code-Analyse. Re-factoring hat leider den bloeden Nachteil das man (von 
aussen betrachtet) erstmal am Verschlimmbessern ist, bis der Mehrwert 
sichtbar wird.

Da hatte ich mal vor langer Zeit brauchbares von benutzt

https://www.scitools.com/

Um wie viele Zeilen geht es denn? 50.000? Da hat man doch nach ein paar 
Tagen den Überblick, wie der Kram funktioniert.

Mark B. schrieb:
> Sieh es vielleicht mal von der Warte:
> Ob ihr den alten Code beibehaltet oder nicht, ist dem Kunden völlig
> schnurzpiepegal. Ihn interessiert die Funktionalität. Das was bisher
> funktioniert hat soll auch weiterhin tun, außerdem soll jetzt neue
> Funktionalität hinzukommen.
Rein von der Funktionalitaet stimmt das natuerlich. Allerdings ist "Neu 
machen" eben teurer, und das muss man dem Kunden schon irgendwie 
verkaufen koennen. Das "Not invented by me" Syndrom von Programmierern 
taugt leider nur bedingt als Argument. Der Kunde sieht ja nur: Jetzt 
funktionierts doch auch, warum soll ich 200 Stunden arbeit bezahlen und 
hab dann hinterher genau das selbe?

Mark B. schrieb:
> Gibt es irgendwo niedergeschriebene Anforderungen? Ein Lastenheft oder
> Pflichtenheft? Ein Dokument zur Systemarchitektur? Irgendwas?
Das waer schoen, aber nein. Allerdings ist das hier auch nicht unbedingt 
das Thema (obwohl ich die Gedankengaenge als Hilfe sehr zu schaetzen 
weiss) - die Moeglichkeit, (Fremd)code relativ schnell uebersichtlich 
und anschaulich zu machen ist aus Prinzip schon interessant. Das kann 
Code von anderen (Fremd)firmen sein, aber auch 10Jahre alter Code aus 
dem eigenen Haus von jemandem, der nicht mehr in der Firma arbeitet. 
Oder einfach nur Code in total anderem Stil.

Einer schrieb:
> Um wie viele Zeilen geht es denn? 50.000? Da hat man doch nach ein paar
> Tagen den Überblick, wie der Kram funktioniert.

Stimmt - es geht in diesem Fall um eigentlich nicht so viel Code, 
vielleicht 10000-12000 Zeilen, mit dazu kopierte Bibliotheken (also noch 
wieder Fremdcode). Das ganze ist allerdings ganz schoen unuebersichtlich 
aufgezogen, voll mit auskommentierten Bloecken und schon die Benennung 
von Objekten haut hinten und vorne nicht hin (die Funktion LEDtest() zB 
testet nicht das LED-Array auf dem PCB (angesteuert durch led.c/.h) 
sondern die digitalen Ausgaenge, an denen, pro Ausgang, eine LED den 
jetztigen Zustand anzeigt). Das ist funktional gesehen noch trivial, 
gibt aber vielleicht einen Eindruck von der Qualitaet des Codes.

Also, das jetztige Projekt war nur der Anstoss des Gedanken ob und wie 
man (Fremd)code schnell uebersichtlich machen kann.
Da waren auch jetzt ein paar Vorschlaege dabei, ich guck mir das im 
Laufe des Tages Mal an. Vielen Dank auf jeden Fall fuer alle Anregungen 
und das Mitdenken. Toll