Source lesen und verstehen lernen
-
Hi, ich hab schon das eine oder andere mal in etwas größere Projekte geschaut.
Um zu sehen, wie weit ich mich in den Code eingelesen bekomme.
Das ging dann sehr schnell gegen die nächstgelegen Wand und ich kam nicht wirklich voran.Jetzt wollte ich euch mal fragen, wie ich das angehen sollte, wenn ich mich in etwas komplexeren Code einlesen will.
Gibt es da Wegen, die man am besten gehen sollte um noch zu verstehen, was vor sich geht.
Ich versuche meist erstmal die main funktion zu lokalisieren, aber auch die lässt sich teils nicht so leicht finden.Wenn ich mir jetzt z.B. mal Gimp nehme oder auch ne Linux Source, wo würdet ihr mir empfehlen anzufangen ?
Wäre gut, da etwas hilfe zu kriegen.
-
Mit der Dokumentation/Readme zum Source.
-
^^es gibt tools, die dir helfen, fremden code zu analysieren, z.b. das: http://www.sourceinsight.com/
oder das: http://www.scitools.com/products/understand/
oder du fütterst doxygen damit und machst dir html mit links usw. daraus.
-
Nicht zu vergessen wäre der Debugger.
-
Falls du eine Programmiersprache lernen moechtest, dann bestimmt nicht ueber den weg, Sourcecode anderer zu lesen und versuchen zu verstehen.
-
knivil schrieb:
Falls du eine Programmiersprache lernen moechtest, dann bestimmt nicht ueber den weg, Sourcecode anderer zu lesen und versuchen zu verstehen.
-
Am besten du versuchst dir einen Überblick über die einzelnen Komponenten im Projekt zu verschaffen (z.B. Datenspeicherung, Anzeige, Verarbeitung/Berechnungen usw...). Dann musst du wissen wie diese grob zusammenarbeiten (z.B. welche Verarbeitungskomponenten greifen auf die DB zu). Anschließend kannst du dir eine Komponente raussuchen und dir deren Code anschauen.
Im Idealfall ist die Zusammenarbeit der Komponenten schon dokumentiert.
-
Ok Dokumentation/Readme hätt ich selbst drauf kommen können ^^
+fricky gute tips, aber ich werd es wohl erstmal ohne Programmunterstützung versuchen, wird ja wohl möglich sein.
knivil es geht mir nicht darum programmieren zu lernen, dass würde ich sicher anders anfangen. ^^
Chris++ so in etwas würde ich es wohl auch angehen, dazu müsste ich nur erstmal einen logischen einstiegspunkt finden, um überhaupt zu erkennen, welche teile des Programms, wann und wozu aufgerufen werden.
Hab ihr selbst auch schonmal versucht die sourcen von Linux oder komplexeren Programmen zu analysieren ?
Mir geht es hierbei nicht darum mir das Programmieren beizubringen sondern darum zu sehen, wie Software so strukturiert wird, was guter Stil ist und wie in Projekten gearbeitet wird, kenne ja bisher nur meinen eigenen Stil und würde da gern mehr zu lernen.
-
Ob die Struktur von Linux oder anderen größeren Projekten beispielhaft ist, sei mal dahingestellt. Im schlimmsten Fall wirfst Du Deine gute Strukturierung über Bord und orientierst Dich zukünftig an einem Negativbeispiel.
Es ist auch für einen einzelnen ziemlich schwer (um nicht zu sagen unmöglich), so umfangreiche Projekte überblicken zu können. Das geht dann nur in Teilbereichen.
-
meistens will man ja nicht direkt ein ganzes Programm überblicken sondern nur eine bestimmte Funktionalität nachvollziehen/ändern können.
Da ist für mich das wichtigste, schnell und einfach von funktion zu funktion springen zu können, alle Vorkommnisse eines strings oder so in der Datei (bzw. in allen) zu finden. Debug-Ausgaben einfügen oder direkt mit nem Debugger durchgehen kann auch helfen.
Darum:
ZSchneidi schrieb:
aber ich werd es wohl erstmal ohne Programmunterstützung versuchen, wird ja wohl möglich sein.
Nein.
Es müssen aber natürlich keine zighundert € teuren Programm sein.
-
ZSchneidi schrieb:
+fricky gute tips, aber ich werd es wohl erstmal ohne Programmunterstützung versuchen, wird ja wohl möglich sein.
Möglich ja aber nicht unbedingt sinnvoll, ne.
knivil es geht mir nicht darum programmieren zu lernen, dass würde ich sicher anders anfangen. ^^
Aha. Du willst ein Programm lesen können, ohne programmieren zu können. Viel Erfolg!
Chris++ so in etwas würde ich es wohl auch angehen, dazu müsste ich nur erstmal einen logischen einstiegspunkt finden, um überhaupt zu erkennen, welche teile des Programms, wann und wozu aufgerufen werden.
Jo. Einfache Lösung: lern programmieren.
Hab ihr selbst auch schonmal versucht die sourcen von Linux oder komplexeren Programmen zu analysieren ?
Andere komplexere Programme: sehr oft, in der Arbeit.
Mir geht es hierbei nicht darum mir das Programmieren beizubringen sondern darum zu sehen, wie Software so strukturiert wird, was guter Stil ist und wie in Projekten gearbeitet wird, kenne ja bisher nur meinen eigenen Stil und würde da gern mehr zu lernen.
OMFG.
Wieso willst du das wissen? Ich ahne Schreckliches! Du willst Projektleiter werden, ohne selbst Programmieren zu können.
Eueueueu....
-
An sich ist die Programmierpsrache volkommen egal, solange die Klassen und Funktionen aussagekräftige Namen haben. Wenn man "nur" die Struktur verstehen will, dann muss man das was wird wann gemacht verstehen, aber nicht das wie. Dazu muss man nicht programmieren können, aber es macht es halt leichter auf die Frage warum etwas so gemacht wurde zu antworten. Der Debugger ist ein äußerst nützliches Hilfmittel dafür, denn man geht den Programmfluss einfach durch und sobald einem der Funktionsname nicht aussagekräftig genug ist, dann spring man in die Funktion hinein und versucht sie zu verstehen.
-
@Fusel.Factor: viele Konstrukte kann man bei aussagekräftigen Namen verstehen, wenn man nicht programmieren kann, ja.
Diverse Dinge wird man aber nicht behirnen.Denk mal an Events in C#, anonyme Funktionen, Algorithmen und Funktoren in C++ etc.
Also es gibt einiges wo sogar ich als erfahrener C++ Programmierer mal nachdenken muss was zum Geier das wohl macht. Trotz sprechender Namen. Wie soll das dann bitte jemand verstehen der nicht programmieren kann?
Vor allem schreibt er ja
Mir geht es hierbei nicht (...) sondern darum zu sehen, wie Software so strukturiert wird, was guter Stil ist und wie in Projekten gearbeitet wird
Wie man das verstehen will, ohne wenigstens halbwegs programmieren zu können, entzieht sich mir vollkommen.
-
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten, dort kann man einfach Doxygen darüber jagen und sich die Beziehungen der Klassen zueinander anschauen um schon einmal die Struktur auf großer Ebene zu sehen.
In C geht das leider nicht, da hilft nur einen Startpunkt aussuchen und von dort an alle inkludes rekursiv durcharbeiten und dabei immer header + quellcode zu durchstöbern. Man sollte hierbei natürlich eine TAG Datenbank verwenden, also erst einmal ctags, etags, GNU Global oder cscope installieren und eine Tag Datenbank erzeugen für das Projekt, dann kann man auch zügig zwischen einzelnen Dateien hin und her springen und sich anschauen wo überall eine Funktion benutzt wird, oder von der Definition zur Deklaration springen.Mach dir nichts vor, ohne Tools geht es nicht.
-
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
Kann man in C seit neuestem nicht mehr OOP programmieren oder was soll das bedeuten
-
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
ach nö, in gut gemachten C-projekten gibts auch funktionale einheiten, die bestimmte aufgaben übernehmen, öffentlich schnittstellen, private attribute, usw. kannste so pauschal nicht sehen, dass nur OO-programme gut analysierbar sind.
-
knivil schrieb:
Falls du eine Programmiersprache lernen moechtest, dann bestimmt nicht ueber den weg, Sourcecode anderer zu lesen und versuchen zu verstehen.
Ging bei mir damals mit BASIC ganz prima
Wenn man im Übrigen ein wenig Ahnung vom Zugrundeliegenden hat, ist es auch halbwegs machbar, sich eine der modernen Sprachen auf diesem Wege anzueignen. Auch wenn es natürlich stets die extremste Form der Autodidakik mit sämtlichen ihrer Probleme darstellst.
-
+fricky schrieb:
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
ach nö, in gut gemachten C-projekten gibts auch funktionale einheiten, die bestimmte aufgaben übernehmen, öffentlich schnittstellen, private attribute, usw. kannste so pauschal nicht sehen, dass nur OO-programme gut analysierbar sind.
Klar, aber kurzes Nachdenken liefert die Erkenntnis, dass diese nur Konventionen sind und somit in Doxygen, oder anderen Dokumentations-/Quellcodetools nicht sichtbar sind.
-
Sorry war übers Wochenende nich da ..
hustbaer : das seltsame ist, das ich mit keinem Wort erwähnt habe, dass ich nicht programmieren kann ^^
Ich sagte nur, dass wenn ich programmieren lernen wollte, dass ich es nicht so anfangen würde.Geh mal davon aus, dass wenn ich schon sourcen analysieren will, dass ich schon programmieren kann, sonst würde das kaum Sinn ergeben oder ?
Linux-Progger : genau den Ansatz der rekursiven analyse hab ich versucht, z.B. bei Gimp, das war schon etwas komplexer, hab ja mit so großen Projekten bisher noch nicht gearbeitet, mit entsprechendem Zeitaufwand sicherlich zu machen.
Das Problem war das nur, dass so gut wie kaum dokumentation vorhanden war und ich so nach dem 10 header mit source dann schon so viele sourcen auf hatte, dass ich leicht den überblick verlohren habe auf welche inhalte sich die header noch beziehen.Wenn ich jetzt davon ausgehe ich möchte in solcher Software nur bestimmte funktionen lokalisieren, hat mich dieses vorgehen leider nicht so sehr weiter gebracht und die namensgebung half mir da nicht so sehr weiter, ich bekomm zwar nen grobem eindruck was die aufgabe sein könnte, aber mir fehlt dann noch der überblick worauf sich änderungen überall auswirken könnten und wo es evtl. probleme verursachen könnte änderungen vorzunehmen.
Ich werde nochmal in eine etwas kleinere hoffentlich überschaubarere Source reinschauen um zu sehen, wieviel ich davon verinnerlichen kann.
Würde nur gern wissen, ob hier jemand schon diesen weg gegangen ist um z.B. an Linux selbst zu arbeiten oder auch irgendwelcher größeren Anwendungssoftware.
Und wie ihr dabei vorgegangen seid.hustbaer : du sagst du machst das auf Arbeit ?
wie sieht das bei dir aus ? Welchen weg gehst du dabei ?
-
Linux-Progger schrieb:
+fricky schrieb:
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
ach nö, in gut gemachten C-projekten gibts auch funktionale einheiten, die bestimmte aufgaben übernehmen, öffentlich schnittstellen, private attribute, usw. kannste so pauschal nicht sehen, dass nur OO-programme gut analysierbar sind.
Klar, aber kurzes Nachdenken liefert die Erkenntnis, dass diese nur Konventionen sind und somit in Doxygen, oder anderen Dokumentations-/Quellcodetools nicht sichtbar sind.
klar, aber ein wenig praktische erfahrung liefert die erkenntnis, dass es egal ist. ich hab' z.b. mit understand C und C++ projekte und mit 'visual uml' Java-projekte seziert. im grunde können reverse engineering tools immer nur eine grobe 'mittlere' struktur sichtbar machen (was natürlich schon sehr hilfreich ist). aber was die feinheiten angeht und den blick aus der vogelperspektive muss man sich selbst erarbeiten. wie schnell man's schafft, hängt z.b. davon ab, ob die programmierer der software gnadenlose abstrahier-freaks oder pragmatiker waren.
