Hallo, ich bin eigentlich kein Programmierer und habe jetzt die Grundlagen von Python gelernt, mit dem Ziel Addons für das Mediencenter Kodi zu erstellen bzw. vorhandene abzuändern. Was ich aber überhaupt gar nicht verstehe: Wie kann ich die Funktionsweise fremden Quellcodes nachvollziehen? Die für Kodi geschriebenen Addons sind vergleichsweise übersichtlich, meistens bestehen sie aus einem halben Dutzend *.py-Dateien, jede einzelne enthält vielleicht Code im Umfang von 4-5 DIN A4-Seiten. Aber alles was ich sehe, sind die Dateien und einen Haufen von Klassen samt ihren Funktionen.... Ich stelle mir das so vor wie in Zeiten von Basic- oder TurboPascal: Es gibt einen Startpunkt, wo das Programm beginnt und anschließend werden diese und jene Zeilen abgearbeitet. Zwischendurch verzweigt das Programm und/oder ruft eine Funktion auf, die dann diesen oder jenen Rückgabewert liefert. Wie kann so etwas aus dem Code herauslesen?
Eine der wichtigsten Aufgaben eines Programmierers ist die Suche nach passender Dokumentation. Für Kodi z.B: https://kodi.wiki/view/Add-on_development Bei "add-ons" gibt is üblicherweise eine dokumentierte API gegen die man programmiert. Wenn man sich nur die .py Dateien anschaut, dann fehlt genau jene Information wie das Ganze benutzt wird.
Wenn das Addons für Kodi sein sollen, dann wird Kodi vermutlich ein API dafür haben. "Vermutlich", weil ich nie Kodi Addons programmiert habe. Ich gehe nur davon aus, dass es bei Kodi so ist wie es es sonst auch üblich ist. Um den Code von diesen Addons zu verstehen musst du das API von Kodi kennen. Dort wird es so etwas wie Eintrittspunkte geben. Das sind Stellen wo das API vorschreibt welchen Code ein Addon wie bereitzustellen hat damit Kodi das Addon einbinden und aufrufen kann.
Gewissenhaft arbeitende Programmierer versehen ihre Quellen mit Kommentaren. Alle anderen erwarten von etwaigen Lesern ein erhöhtes Maß an Genialität. Das macht den Unterschied aus. W.S.
W.S. schrieb: > Gewissenhaft arbeitende Programmierer versehen ihre Quellen mit > Kommentaren. Alle anderen erwarten von etwaigen Lesern ein erhöhtes Maß > an Genialität. Das macht den Unterschied aus. Auch wenn ich dieser Aussage grundsätzlich zustimme: Trotzdem erklärt man in den Kommentaren nicht, wie das Framework, die API oder was auch immer funktioniert. Die notwendigen Grundlagen muss der geneigte Leser schon selbst schaffen, Kodi hätte z.B. dieses hier: https://kodi.wiki/view/Add-on_development Auch Entwurfsmuster erklärt man nicht in Kommentaren und noch eine Reihe anderer Dinge. Ja, das bedeutet, dass mancher Code eine erhebliche Vorbildung erfordert, und es ist nicht die Aufgabe des Programmierers, dir diese über Kommentare zu verschaffen.
Viele erklärende Kommentare im Quelltext sind störend und eine potenzielle Fehlerquelle. Wenn sich die Funktionalität im Code ändert kann vergessen werden die Kommentare zu aktualisieren. Ein guter Code muss so weit wie möglich selbsterklärend sein. Und ab einer gewissen Größe ist eine vernünftige Dokumentation sehr sinnvoll, um die Zeit für die Einarbeitung erheblich zu reduzieren. Bei mir läuft es so ab dass ich mir einen Quellcode einfach lange genug ansehen muss um es zu verstehen. Sofern es kein riesiges Projekt ist. Ich versuche den Programmablauf zu verfolgen und zu verstehen was in den einzelnen Abschnitten passiert. Dabei muss man sich immer wieder merken was und wie die einzelnen Elemente und Abschnitte tun. Am Anfang vergesse ich immer wieder die genauen Abläufe die ich mir vorher angesehen habe. Dafür reicht einfach mein Kurzzeitgedächtnis nicht aus :D Ich muss mit den Code also so oft anschauen bis die angesehenen Strukturen im Gedächtnis länger verbleiben. Und erst dann werden die Zusammenhänge klar und was das Programm macht.
aschafmeister schrieb: > ich bin eigentlich kein Programmierer Nun, niemand ist das von Geburt an. Man muss das lernen. Wie jedes andere Handwerk auch. > Wie kann ich die Funktionsweise fremden Quellcodes nachvollziehen? Das geht nur, wenn du halt (zumindest) selber Programmieren kannst. Oft ist aber auch noch Wissen darüber hinaus nötig. Um das Konzept zu verstehen, was der fremde Code umsetzt. > Ich stelle mir das so vor wie in Zeiten von Basic- oder TurboPascal: > Es gibt einen Startpunkt, wo das Programm beginnt und anschließend > werden diese und jene Zeilen abgearbeitet. Nö, gerade bei Plugins wäre das (naturgemäß) ziemlich atypisch. Typisch interagieren die mit dem Hauptprogramm über einen Satz von "callback-Funktionen". Haben also eine sog. ereignisorientierte Struktur. Nur in dem Fall, dass es nur einen einzelnen Callback als Interface gibt, könnte sich die von dir so schmerzlich vermisste klassische Programmstruktur für das Plugin mal rein zufällig ergeben... Sprich: Lerne programmieren. Lerne "ereignisorientiert" zu programmieren. Dann klappt das schon mit dem Verständnis der Plugins...
CleanCoder schrieb: > Ich muss mit den Code also so oft anschauen bis die angesehenen > Strukturen im Gedächtnis länger verbleiben. Und erst dann werden die > Zusammenhänge klar und was das Programm macht. Genau. Natürlich schadet es nicht, von den Einsprungspunkten zu starten ;-) Aber ganz wichtig, man muss die "Gramatik" bzw. das typische Zusammenspiel der Token erfahren. Und da hilft nur lesen. Manche Muster können die Entwickler nicht mal beschreiben, weil sie sie "für selbstverständlich" halten, obwohl sie anderen unbekannt sind. Das WIE kann nur im Code stehen. Doku kann nur das WAS beschreiben (und sollte es auch), das WARUM ist dann meist nur in Tickets oder Korrespondenz zu finden. Klar wären da richtige Dokumente und Listen besser, aber man kann nicht alles erwarten. Solange das, was da ist, noch aktuell ist, muss man schon zufrieden sein.
aschafmeister schrieb: > Wie kann ich die Funktionsweise fremden Quellcodes nachvollziehen? Letztendlich ist das harte Arbeit. Vor allem am Anfang ist es schwer. Im Zweifel muss man allen Code lesen und verstehen. Dabei muss man halt erkennen, was sich der ursprüngliche Programmierer gedacht hat, und welche Abstraktionen er sich ausgedacht hat. Je mehr man mit fremden Code konfrontiert wird, je mehr man selbst programmiert, desto mehr Erfahrung sammelt man. Je mehr Erfahrung man hat, desto eher erkennt man Abstraktionen, Konzepte und Ideen hinter Code. Selbst lese ich sehr gerne fremden Code. Mir macht es sogar mehr Spaß, bestehenden Code zu erweitern oder anzupassen, als auf der grünen Wiese zu beginnen. Ich finde, man kann am Code die Denkweise von anderen Programmieren "lesen". Aber das ist schon etwas abgefahren. Es ist wie bei einer mechanischen Maschine. Du kannst die zwar zerlegen, jedes Teil vermessen, aber nur wenn Du genau erkennst und verstehst, warum die Teile in einer bestimmten Art und Weise konstruiert worden sind und wie sie zusammenwirken, verstehst Du die Maschine. Für elektronische Schaltungen gilt das selbe. Du kannst alle Widerstände, Kondensatoren und Transistoren auflisten und alle genau ausmessen. Aber zum Verstehen der Schaltung, warum hier und dort ein Bauteil eingebaut wurde, musst Du deutlich mehr Erfahrung und Wissen mitbringen. Das kommt mit der Zeit, ist aber harte Arbeit.
Wenn man es beruflich nicht schon macht sollte man fremden Code eigentlich schon regelmäßig lesen. Am besten einfach auf Github gehen und sich etwas raussuchen und dass dann versuchen zu verstehen.
Als Anfaenger sollte man sich nicht grad sofort fremdem Code widmen. Da sollte man auch erst fix mit dem Debugger sein.
Fremden Programmcode nachvollziehen - Wie ? GARNICHT Wenn du es nicht unbedingt musst, LASS ES. Jeder noch so schlechte Programmierer schreibt das was der Code machen soll, schneller selbst als durch ein fremden Code durch zu blicken. Und den einzigen Code der wirklich so dokumentiert ist, das ihn ein Anfänger versteht habe ich mal in einen der "für Dummies" Buch gesehen. Also. VERGISS es. Zum lernen sind fremde Codes einfach Mist. Diese Ausage gilt aber klar NICHT für Codeschnipsel. Die sind immer sehr lehrreich weil sie die Funktion einen Befehls erklären. Ohne viel drumherum. Bei einen fremden Code musst du nämlich 2 Dinge verstehen. Den CODE UND die Gedanken den Programmierers. Und das ist super schwer.
Vielen Dank für die Ratschläge. c-hater schrieb: > Nö, gerade bei Plugins wäre das (naturgemäß) ziemlich atypisch. Typisch > interagieren die mit dem Hauptprogramm über einen Satz von > "callback-Funktionen". Ja, vor allem weil nicht nur das interessierende Addon mit dem Hauptprogramm interagiert, sondern im Hintergrund ein ganzer Haufen von Addons läuft. Purzel H. schrieb: > Als Anfaenger sollte man sich nicht grad sofort fremdem Code widmen. Da > sollte man auch erst fix mit dem Debugger sein. Speziell für Kodi habe ich folgenden Debugger gefunden und werde versuchen, mit dessen Hilfe die Funktionsweise des Addons nachzuvollziehen: https://github.com/romanvm/python-web-pdb
Schlaumaier schrieb: > GARNICHT > > Wenn du es nicht unbedingt musst, LASS ES. Jeder noch so schlechte > Programmierer schreibt das was der Code machen soll, schneller selbst > als durch ein fremden Code durch zu blicken. Das gilt für Ein-Mann-Projekte. Als echter Programmierer wirst Du es mit Scheuklappen als Einzelkämpfer nicht weit bringen. > Und den einzigen Code der wirklich so dokumentiert ist, das ihn ein > Anfänger versteht habe ich mal in einen der "für Dummies" Buch gesehen. Das ist so, als würde man sich ein Mofa, ein Auto, eine Uhr nur anschauen, wenn auch entsprechende Dokumente dabei sind. Nein. Wenn die gut gemacht sind, erschließt sich das Zusammenspiel auch dem Laien durch probieren, schauen und bei SW: Diagnose-Ausgaben. Und lernen kann man trotzdem.
A. S. schrieb: > Das gilt für Ein-Mann-Projekte. > > Als echter Programmierer wirst Du es mit Scheuklappen als Einzelkämpfer > nicht weit bringen. Nicht ganz richtig. Wenn ich in einen Team programmiere, gibt es klare Regeln. Diese sind für das Team vorher festgelegt. Da muss ich nicht durch den Code meines Kollegen durchblicken, sondern ich muss ihn nur den Regeln nach interpretieren. Ansonsten hast du nämlich genau mein beschriebenes Chaos. Ich musste 1 x ein Code analysieren. Das Ergebnis nach 2 Wochen war, das ich den Mist mit sein Spagetti-Code sein hab lassen, und bis auf die Ansteuerungsroutine des Gerätes die ganze Umgebung neu geschrieben habe. Es gibt je nach Team sogar Vorschriften wie Schleifenvariablen zu nennen sind. Von normalen Variablen mal ganz abgesehen. Was den "Einzelkämpfer" angeht. Ich habe es damit bis fast zur Rente gebracht. Fehlen nur noch ein paar (ca.4-5) Jahre falls die Regierung nicht was ändert. Und Auftragsprogrammierer werden sehr oft noch gesucht. In allen Formen + Farben so zu sagen ;) Allerdings geht die Tendenz zu Hardware-Programmierer, das gebe ich zu.
Schlaumaier schrieb: > Es gibt je nach Team sogar Vorschriften wie Schleifenvariablen zu nennen > sind. Von normalen Variablen mal ganz abgesehen. Lustig ist, das gerade sowas eigentlich völlig unwichtiger Bullshit ist. Es ist eher so, das gerade solche Konventionen (wenn man sie erstmal tief verinnerlicht hat), einen dramatisch dabei behindern, sich effizient in ANDEREN fremden Code einzuarbeiten. Nein, das ist Gülle. Namenskonventionen gibt es nämlich mindestens so viele wie Projekte... Das ist ein absoluter Nebenkriegsschauplatz. Nur Anfänger und Vollidioten halten sich mit sowas ernsthaft auf... Viel wichtiger ist: statt irgendwelche mehr oder weniger schwachsinnige Konventionen einzuhalten, sollten die Namen möglichst "sprechend" sein. Das hilft viel mehr als alles andere. Leider haben das eine Mehrheit der "Entscheider" nicht richtig verstanden. Liegt wohl daran, dass dieser Personenkreis erstens nicht selber programmiert und zweitens auch nicht daran interessiert ist, dass "seine" Programmierer sich mal schnell bei der Konkurrenz (mit besserem Gehalt) verdingen könnten... Aber: sie vermiesen sich damit auch selber den "Einkauf" neuen Menschenmaterials, das ist wohl, was sie nicht begreifen...
Schlaumaier schrieb: > Ich musste 1 x ein Code analysieren. Das ist nach deinen bisherigen Aussagen zum Thema dann doch überraschend häufig. Oliver
A. S. schrieb: > Doku kann nur das WAS beschreiben Das kann in weiten Teilen auch der Code selbst, wenn er entsprechend strukturiert, modular, granular aufgebaut ist. Ein Methodenname sagt, was getan wird, die Methode, wie es getan wird. Wenn man allerding möglichst viel in eine Methode packt und dort nur Frickelkram steht, steht dort nirgendwo geschrieben, was passiert sondern überall nur, wie etwas passiert. Dann müssen dort auch viele Kommentare stehen, und man muß sich ständig alles merken oder immer wieder dieselben Kommentare lesen. Sowas wie eine 11-seitige Methode mit bis zu 10-fach ineinander verschachtelten for/if/switch/case/while-Anweisungen habe ich schon öfter gesehen und halte ich für völlig schwachsinnig. Wer das verbrochen hat bzw. daran arbeitet und seit Jahren nicht umstrukturiert hat, gehört sich m.M.n. gekündigt und in eine Klappsmühle eingeliefert. Solchen Code sollte man refaktorieren. Dabei lernt man dann, was der Kram eigentlich macht und hat am Ende lesbareren Code.
:
Bearbeitet durch User
Oliver S. schrieb: > Das ist nach deinen bisherigen Aussagen zum Thema dann doch überraschend > häufig. YMMD
Markus L. schrieb: > Sowas wie eine 11-seitige Methode mit bis zu 10-fach ineinander > verschachtelten for/if/switch/case/while-Anweisungen habe ich schon > öfter gesehen und halte ich für völlig schwachsinnig. Definitiv ist das unschön. Allerdings habe ich auch schnell gemerkt dass man auch ein gegenteiliges Extrem verursachen kann. Wenn eine Funktion über so viele Methoden verteilt ist, dass man im Grunde Mühe hat sich die einzelnen separierten Abläufe zu merken und den roten Faden kaum erkennt. Jedes mal wenn man so eine einzelne Methode betrachtet, muss man überlegen was die vorangegangenen Methoden taten und was folgende Methoden noch tun werden. So springt man hin und her im Code und versucht den Ablauf zu verstehen. Was in Ordnung ist wenn die Aufteilung sich in Grenzen hält.
c-hater schrieb: > sollten die Namen möglichst "sprechend" sein. > Das hilft viel mehr als alles andere. Dazu habe ich ein "gutes" Beispiel:
1 | .EQU ENC_B_SNSREG = EICRA ;diese drei Werte m³ssen konfiguriert |
2 | .EQU ENC_B_SNSMSK = (1<<ISC11)|(1<<ISC10) ;werden f³r INTx. Und zwar f³r Sensibilitõt |
3 | .EQU ENC_B_SNSVAL = 1<<ISC10 ;in beiden Richtungen. |
c-hater schrieb: > sollten die Namen möglichst "sprechend" sein. > Das hilft viel mehr als alles andere. Dazu habe ich ein "gutes" Beispiel:
1 | .EQU ENC_B_SNSREG = EICRA ;diese drei Werte müssen konfiguriert |
2 | .EQU ENC_B_SNSMSK = (1<<ISC11)|(1<<ISC10) ;werden für INTx. Und zwar für Sensibilität |
3 | .EQU ENC_B_SNSVAL = 1<<ISC10 ;in beiden Richtungen. |
Ist wirklich nicht böse gemeint. Aber ENC_B_SNSMSK hätte ich z. B. ENC_B_SNSUP und ENC_B_SNSVAL mit ENC_B_SNSDOW benannt - oder ähnlich. MSK steht bei mir für "Mask(e)" und VAL steht bei mir für "Wert". Nur so, am Rande ... :-) (Sorry für den Halb-Doppel-Post" - falsch geklickt ...)
:
Bearbeitet durch User
Beitrag #6825117 wurde von einem Moderator gelöscht.
Wenn man anderer Leute Code analysieren muss, musss man nehmen, was da ist. Aber man kann es selber besser machen. Ich empfehle die Bücher: - "Clean Code" von Martin Robert C oder - "Clean Code für Dummies" von Jürgen Lampe (beide in Deutsch)
aschafmeister schrieb: > Wie kann ich die Funktionsweise fremden Quellcodes nachvollziehen? Das ist nicht trivial! Im Grunde läuft das genauso wie das normale Lesen und Schreiben lernen in der Schule - allerdings ohne so wunderschön entwicklungsbegleitet zu sein. Aber aus der Elektronik kennen das sicher viele auch - wer schon als Kind Fernseher auseinandergenommen und wieder zusammengebaut hatte.. Der Blick für etwas, die Mustererkennung kommt mit Know How, Erfahrung, vielen vielen Lernrunden und viel Lernmaterial. Der typische Weg, wie man zum Fachidioten wird z.B. Um mal bei dem Schulbeispiel zu bleiben: es gibt ja nicht nur lern-freundliche Texte, manche Texte sind in Englisch, oder Spanisch, die kann man vielleicht erstmal noch nicht verstehen, manche Texte sind in Fachchinesisch, oder wissenschaftlich, die wird man auch nicht gut verstehen ohne Erfahrung oder ohne gutem Verständnis des fachlichen Hintergrundes. Es gibt noch ein anderes gutes Beispiel: Wie beim Schach gewinnen? Auch dieses fällt leichter, wenn man bestimmte Grundtechniken kennt, wenn man an Wettkämpfen teilnimmt, wenn man sich theoretisch einarbeitet, spielerisch drumherum rechnet, ausprobiert immer wieder übt. Mit der Zeit kommt die Mustererkennung.. Klingt vielleicht schlimmer, als es ist, z.B. weiß ich noch recht gut, dass ich für das Uhrenlesen eine Weile gebraucht hatte. In einem Nachbardorf gab es mal Zwillinge, die sahen sich sehr ähnlich. Am Anfang konnte ich die überhaupt nicht unterscheiden, später irgendwann dann aber doch sehr gut und auf den ersten Blick. Es gibt ja z.B. auch Bücher wie "C++ in 21 Tagen". Aber das ist Quatsch, s.o. Ein erfahrener Entwickler meinte diesbezüglich mal, so ab 2 Jahren Vollzeit Engagement + Vorerfahrungen ist man gut dabei.
Ich kann kein Englisch. Aber trotzdem kann ich mich immer "irgendwie durchmogeln". Als ich 1998 mit VBA angefangen habe, hatte ich fremden VBA-Code analysiert. Damals hat mich das Aus- und Einblenden von Zeilen und Spalten interessiert. Also fremden VBA-Code genommen, Zeilen- und Spaltenangaben angepasst, und schon lief es. War für mich eigentlich ganz leicht. Ein bisschen analytisches Verständnis kann dabei nicht schaden. Genauso habe ich HTML, PHP und CSS gelernt. Den Code laufen lassen, geschaut was passiert (vor und nach dem Anpassen), und dann für mich angewendet. Nur bei .Net tue ich mich schwer. Ich hatte auch VBA-Bücher, bis ich mich belehren lassen musste, dass nicht in allen Büchern sauberer Code steht (besonders bei einem bekannten Autor dessen Namen ich hier nicht nennen möchte), aber man kann auch aus Fehlern lernen die andere gemacht haben.
:
Bearbeitet durch User
Hallo René H., René H. schrieb: > (besonders bei einem bekannten Autor dessen > Namen ich hier nicht nennen möchte) warum nicht? Ich brauche zwar keine VBA-Bücher, aber beim nächsten Bücherei- oder Buchhandlungsbesuch würde ich gerne mal einen Blick drauf werfen!
Im Prinzip ist die Arbeit des Verstehens von fremden Systemen die selbe Arbeit wie bei der Rückentwicklung. Während man bei der Entwicklung von einer Idee zu einem Artefakt (z.Bsp. Schaltung, Programmcode, usw) kommt, kommt man bei der Rückentwicklung vom Artefakt zu den Ideen dahinter. Als erstes sollte man sich klar werden, was man überhaupt machen will. Nur selten will man ein Artefakt als Ganzes verstehen. Viel häufiger ist es, dass man eine Änderung an einem Artefakt vornehmen möchte, um zum Beispiel einen Fehler zu beheben. Im letzteren Fall ist es nicht notwendig alles zu verstehen. Irgendwo muss man anfangen. Will man zum Beispiel verstehen, warum ein Computerprogramm einen bestimmten Fehlertext ausgibt, so hilft es nach diesem Fehlertext zu suchen um einen Einstiegspunkt zu finden. Von diesem Punkt an kann man sich Stück für Stück durchhangeln um bis zu dem eigentlichen Fehler zu kommen.
Nachdem du dir in ein dutzend Addons angeschaut hast, wirst du sehen, einige sind klar und verständlich geschrieben. Andere sind so verknotet - da steigt man nicht durch. Wenn sich die Funktionsweise nicht verstehen lässt, gibt es zwei Gründe. Das Programm benutzt eine geniale Strategie, von Mathematikern ausgearbeitet. Du musst dich in die Mathematik einarbeiten. Das lohnst sich! Oder das Addon stammt von irgendwelchen inkompetenten Chaoten. Einfach ignorieren und das nächste Addon anschauen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.