Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Einarbeitung in fremden Code
Hey, mal ne Frage. Wie arbeitet ihr euch in umfangreichen Code ein? Habt ihr da spezielle Methoden?
Muss mich in ne komplexere Website einarbeiten(mix aus php, javascript, html, css, MySQL). Hab erstmal den Code durchgelesen. Und überlege jetzt im zweiten schritt vielleicht mit UML-ähnlicher Notation mal zu visualisieren welche Teil wie zusammenhängen.
Was macht ihr so wenn ihr euch in Fremden Code einarbeiten müsst?
1 „Gefällt mir“
Mir hilft es, wenn ich mir einen bestimmten Kontrollfluss etwas genauer anschau (z.B was passiert im Code wenn ich Button X drücke…vorrausgesetzt der Code erzeugt so etwas wie Buttons;). Anschließend irgendeine (gerne auch Sinnfreie) Implementierung dem Code hinzufügen, in der man idealer weiße die gegebene code-infrastruktur schon etwas mitbenutzt.
Ich mach das genauso wie axelmt, wichtig ist hier eine gute IDE zu haben, die einem beim Springen durch den Code unterstützt und auch mal Suchen wie “Wo übreall wird Variable XY benutzt?” erlaubt. Weiß jetzt aber nicht, welche Möglichkeiten man da bei PHP hat.
Es hängt davon ab, wie gut du den Aufbau des Codes im Kopf behalten kannst. Ich kann das anscheinend recht gut, aber ein guter Freund von mir hat da Probleme. Für so jemanden ist das Erstellen von Diagrammen etc. natürlich enorm hilfreich.
In der Regel will ich das so machen, wie das Skript von meinem Hassfach besagt:
- Versuche zunächst, die Theorie hinter dem Problem sowie die Aufgabe zu verstehen.
- Überleg dir nachher, was der Code vor den Veränderungen macht und nach den Veränderungen machen soll.
- Entwirf anschließend den neuen Code, z. B. mittels UML-Diagrammen.
- Schreibe dann die Veränderungen im Code hin.
- Teste das Programm ausführlich. (Schreibtischläufe, Nebenrechnung, Randfallprüfung etc.).
- Beweise zum Schluss, dass der neue Code auch das tut, was er machen soll.
In der Praxis lasse ich normalerweise den Schritt 3 aus Zeitgründen weg, aber dabei ist es auch, wie Ford Prefect bereits gesagt hat, wichtig, zu wissen, was das Programm macht. Wichtig ist vor Allem die Beachtung von den Schritten 5, 6 und ganz besonders vom Schritt 1.
Das ist eine echt gute Frage. Es scheint eine immer wichtiger werdende Fähigkeit zu werden, Code von anderen lesen und verstehen zu können.
Bei einem größeren Java Projekt hat mir mal ein UML Plugin für Eclipse sehr geholfen, um die Vererbungshierarchie zu überblicken.
Tatsächlich fängt das Problem beim Erzeugen des Codes an. Deswegen kann ich nur jeden Entwickler bitten seinen Code sauber zu kommentieren und zu dokumentieren. Nichts ist schlimmer als sich mit komplexem, nicht verständlichem Code auseinander setzen zu müssen, weil der Andere keine Lust hatte sich Gedanken über eine vernünftige Infrastruktur zu machen. Da man selber nicht nur Code erzeugt, sondern auch selber lesen muss schließt sich der Kreis auch wieder und man wird dafür “belohnt”, dass man vernünftig dokumentiert. Je mehr es tun desto schöner wird die Welt der Entwicklung 
Ansonsten hilft da nur den Code zu lesen und selber versuchen Codeabschnitte mit Kommentaren zu dokumentieren, das hilft beim Verstehen und man macht sich auch mehr Gedanken wenn man versucht einen Codeabschnitt sich selber zu erklären. Außerdem hilft es auch sich an ein Prinzip zu halten, sprich entweder man geht Top-Down oder Bottom-Up beim Analysieren vor. Wobei ich Top-Down bevorzuge, da man in der Regel nicht jede einzelne Funktion auf Ihre Richtigkeit prüfen muss, das erspart viel Arbeit. Das hilft vor allem bei OO-Sprachen. Was Websprachen angeht bin ich nicht so fit, aber ich denke es wäre hilfreich wenn man sich eine Art Glossar zusammenschreibt in dem man Funktionen und Repräsentationen von den verschiedenen HTML/PHP Dateien aufschreibt, das dann wiederum aufschlüsselt in Unterfunktionen usw. Also praktisch ein Reverse Engineering der Dokumentation.
Also das wichtigste ist imho irgendeine Funktion im Editor (ich verwende zB cscope fuer C) um schnell zu der Definition oder den Verwendungen von Sachen springen zu koennen. Mit grep und Konsorten ist es viel zu fummelig irgendwelche komplexeren Kontrollfluesse nachzuvollziehen. Fuer Datenbanken gibts auch einige Skripte um automatisch ER-Diagramme zu bauen, die haben zwar alle Probleme mit komplexeren Layouts (zB Views, zusammengesetzte Schluessel, etc), aber fuer nen groben Ueberblick reichts oft.
Dokumentation ist oft wenig hilfreich weil schnell falsch. Und was fuer den einen offensichtlich ist ist fuer den anderen zu kompliziert und sollte dokumentiert werden. Exzessive Doku fuer “jeden Deppen” ist aber imho Zeitverschwendung. Daher ersetzt Doku nie die Faehigkeit Code zu verstehen.
Nein das sollte man nicht machen, aber ich habe glaube ich auch nicht von „exzessiver Doku“ gesprochen. Ein wenig Doxygen im Code ist immens hilfreich, einfach weil schnelles Navigieren und Nachschauen möglich ist und man sich so schnell ein erstes grobes Bild vom Zusammenspiel der Klassen und Funktionen machen kann. Doku als wenig hilfreich abzustempeln zeigt mir nur wieder, dass eine gewisse Faulheit besteht es anderen einfacher zu machen. Das ist Schade, aber leider oft die Regel. Für mich ist Doxygen zumindest eine einfache Art und Weise um komplexe UML-Diagramme zu vermeiden, die zwar mehr Aussagekraft besitzen, wenn man es richtig macht aber auch deutlich mehr Zeit in der Erstellung beanspruchen, als für ein paar Funktionen und Klassen einen kurzen Kommentarblock zu schreiben. Aufwand ↔ Profit ist da imho besser. Außer es werden zur Erstellung des Projekts bereits automatisierte Tools genutzt, die aus UML, Code generieren. Hierbei ist die Pflege der UML-Diagramme aber wieder ein kleines Problem, weil UML → Code toll, aber Code → UML aua. Kommentare können zwar auch kaskadieren und Schmerzen bereiten in ungünstigen Fällen, aber bei geringer Kopplung zwischen Modulen und hoher Kohäsion in Modulen sollte sich sowas in Grenzen halten. (Wir gehen natürlich von der perfekten Software aus :-D)
“ein wenig Doxygen” ist aber nicht, was ich meine. Wenn eine Funktion aufgrund ihres Namens, der Typen und Namen ihrer Parameter eindeutig anzeigt, was sie tut dann ist alles gut, der Code dokumentiert sich selbst und Doxygen uebernimmt einfach die entsprechenden Informationen, alle sind gluecklich. Ein paar spezielle Umstaende erfordern noch jeweils eine halbe Zeile Text, zB der Hinweis auf eingeschraenkte Wertebereiche der Parameter, die man nicht ins Typsystem packen kann, ueberraschende Randbedingungen oder aehnliche Fallen. Damit sollte dann aber alles erledigt sein. Wenn man zuviel Zeit hat oder wenns noetig ist (z.B. wenn man eine Bibliothek gebaut hat die andere verwenden sollen) kann man natuerlich noch viel mehr zur Verwendung schreiben incl. Codebeispiele, toll zu sehen zB an Qt. Qt ist unter anderem wegen der tollen Doku viel besser als GTK.
All das hilft einem aber wenig bis garnicht beim Verstaendnis der Funktionsweise von Code. In Doxygen steht, was ein Codeteil tut und wie man den verwendet. In Doxygen steht ueblicherweise nicht, wie das passiert. Garnicht zu reden von warum das so und nicht anders geschieht. Dafuer gibts normale Kommentare oder den Code selber. Insbesondere der Code sollte klar sein, um Kommentare ueberfluessig zu machen, denn dann gibts auch keine Probleme mit der Konsistenz der Kommentare zum Code nach Aenderungen. D.h. es ist besser Zeit in schoenen Code zu stecken als in Kommentare, und es spart auch in der Zukunft Zeit, weil jemand der Fehler sucht nicht durch moeglicherweise veraltete Kommentare irregeleitet wird.
Und nicht zuletzt gibts noch das Problem, dass man ueblicherweise fuer Kommentare und Doku nicht bezahlt wird, sondern nur fuer Code. Also laesst man Kommentare sein, oder fuehrt nutzlose Kommentare ein um irgendwelche geforderten Metriken zu erfuellen.
Was ich da hilfreich finde, sind zwei Dinge:
- Tools, die mir automatisch hilfreiche Diagramme zeichnen, damit ich mich auf die Analyse konzentrieren kann, anstatt auf das korrekte Zeichnen:
** z.B. http://www.mysql.com/products/workbench/ sollte meines Wissens nach ein Reverse-Tool enthalten, welches Dir aus einer MySQL-Datenbank EER-Diagramme erzeugt
** php/js : da kenne mich nicht so gut aus, aber da sollte sich was finden lassen; mittels Stackoverflow stößt man z.B. schnell auf PHP_UML und http://www.objectplayground.com/ - Testcases schreiben: Hört sich blöd an, aber das hat mehrere Vorteile:
** ich lerne kennen, was gewisse Funktionen tun und halte dieses Wissen fest (Testcases sind durchaus brauchbare Dokumentationen)
** wenn ich etwas anlange, von dem ich keine Ahnung habe, kann ich die danach alle durchlaufen lassen und zumindest einmal feststellen, ob ich elementarste Dinge ungewollt durch Seiteneffekte o.ä. zerschossen habe