Source lesen und verstehen lernen
-
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.
-
spätestens, wenn man in die Verlegenheit kommt, 100K+ Zeilen an vorhandenen Algorithmen auf neue, erweiterte Datenstrukturen anwenden zu sollen, wird man aber merken, daß manchmal:
$Abstraktion $Abstraktion dient letztendlich dazu, Implementations- und vor allem Denk-Arbeit zu sparen, und das *ist* Pragmatismus, gemäß dem E=mc^2 der Wirtschaft:
$Zeit Geld$
-
u_ser-l schrieb:
Abstraktion dient letztendlich dazu, Implementations- und vor allem Denk-Arbeit zu sparen, und das *ist* Pragmatismus...
nur wenn man's nicht übetreibt. sonst geht die sache nach hinten los.
-
was ich sagen will: Abstraktion und Pragmatismus müssen bei der Programmierung kein Widerspruch sein - gerade, wenn es um Software geht, die später portiert, erweitert oder sonst wie verallgemeinert werden soll. Da stellt sich Abstraktion im Nachhinein oft als der bessere Pragmatismus heraus.
-
u_ser-l schrieb:
was ich sagen will: Abstraktion und Pragmatismus müssen bei der Programmierung kein Widerspruch sein - gerade, wenn es um Software geht, die später portiert, erweitert oder sonst wie verallgemeinert werden soll. Da stellt sich Abstraktion im Nachhinein oft als der bessere Pragmatismus heraus.
das sehe ich genau so. die frage ist nur, wie weit man abstrahieren sollte. zu wenig ist schlecht, aber zu viel auch.
-
ZSchneidi schrieb:
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.Wenn ich mich richtig erinnere, wurde es unterstellt, und du hast die Unterstellung nicht berichtigt. Und damit den Eindruck bei mir erzeugt, du könntest nicht - oder nicht gut - programmieren. Aber egal.
Geh mal davon aus, dass wenn ich schon sourcen analysieren will, dass ich schon programmieren kann, sonst würde das kaum Sinn ergeben oder ?
OK
hustbaer : du sagst du machst das auf Arbeit ?
wie sieht das bei dir aus ? Welchen weg gehst du dabei ?Das ist schwer in ein paar Sätzen zu beschreiben
Wichtig ist erstmal es sich nicht selbst unnötig schwer zu machen. D.h. verwende sämtliche Tools die dir die Arbeit erleichtern könnten.
Tools wie Doxygen, Visual Assist X, ...
Dazu wiederum ist es sinnvoll, wenn du erstmal das Programm bauen kannst. Wenn das nicht baut (wegen falscher Include-Pfade, fehlender externer Dependencies etc.), dann tun sich diverse Tools auch entsprechend schwer, das korrekt zu analysieren.Und dann versucht nicht das Programm als ganzes zu verstehen. Verschaff dir einen groben überblich über den Stil und die verwendeten Patterns des Programms. Jeder Programmierer und jedes Team arbeitet etwas anders, und wenn du ein Feeling dafür entwickelst wie der/die Programmierer so drauf waren, die etwas geschrieben haben, dann tust du dich schonmal leichter. Dazu siehst du dir einfach mehr oder weniger zufällig einige Header-Files und Source-Files an, und guckst einfach was die da alles an Patterns/... einsetzen. Zusätzlich kannst du Doxygen verwenden, z.B. um schöne Vererbungs-Graphen zu bekommen, Cooperation-Graphen (wer ruft was auf, wer verwendet welche Klassen) etc.
Meiste verwende ich nichtmal Tools ala Doxygen dazu, weil es vermutlich länger dauern würde ein Doxyfile zu basteln, Doxygen laufen zu lassen etc., als wenn ich es "ohne Hilfe" macht. Aber wenn das Projekt eine gewisse Grösse hat, dann mache ich das durchaus.
Wenn du deinen "groben Überblick" hast, dann pick dir ein paar Dinge raus die du dir angucken möchtest. z.B. das Plugin Interface bei GIMP, oder was auch immer. Davon siehst du dir dann den Code an, und arbeitest dich halt durch. Dabei helfen ungemein eine gute IDE, und evtl. Tools ala Visual Assist X. Ist halt ein Unterschied ob man eine Funktion die irgendwo aufgerufen wird von Hand suche muss, oder einfach den Cursor auf den Funktionsnamen stellt, und Alt + G drückt
(Dasselbe für Klassen und Variablen)
-
hustbaer : Das war zumindest schon mal ganz hilfreich.
Da die Mehrheit eher dazu neigt, sich der Unterstützung von Tools zu bedienen, werde ich wohl den gleichen Weg versuchen.Da ich unter Linux arbeite kann ich leider nicht auf VAX zurückgreifen, werde mir aber Doxygen mal ansehen und testweise mit kleinerer Software anfangen.
Seltsam ist nur, dass bei den Sourcen immer möglichst wenig documentation vorhanden zu sein scheint ^^ Dann eben den langen weg.
Dank dir erstmal, soweit.
