Fast jeder fortgeschrittene Programmierer sagt, dass es sehr nützlich ist, den Code anderer Profis zu lesen. Normalerweise beraten sie Open Source.
Liest du es oder nicht? Wenn ja, wie oft und wie wird der Code gelesen? Außerdem ist es für Neulinge ein bisschen schwierig, mit SVN umzugehen - ein Bündel von Dateien. Was ist die Lösung?
Antworten:
Liest du es oder nicht?
Ja.
Wenn ja, wie oft?
Täglich. Ständig. Ich arbeite mit zahlreichen Open-Source-Projekten (hauptsächlich mit Python) und muss den Quellcode lesen, da er die genaueste Dokumentation ist.
und wie wird der Code gelesen?
Äh. Öffnen und lesen.
Außerdem ist es für Neulinge ein bisschen schwierig, mit SVN umzugehen - ein Bündel von Dateien. Was ist die Lösung?
Öffnen und lesen. Dann lies mehr.
Es ist nicht einfach. Nichts macht es einfach. Es gibt keinen Königsweg zum Verständnis. Es braucht Arbeit.
Das Rätsel, das Sie haben, besteht aus mehreren Ebenen. Beginnen Sie zunächst auf hoher Ebene sozusagen aus der Vogelperspektive. Sobald Sie ein Projekt ausgecheckt haben, befinden sich eine Reihe von Dateien in einer Verzeichnisstruktur. Das ist das Gleiche, ob Sie Open Source oder Closed Source betrachten (Quellcode ist schließlich Quellcode). Also fang damit an:
Es braucht Übung, aber es ist definitiv machbar. Je mehr Sie über die von der Anwendung verwendeten Bibliotheken und Frameworks wissen, desto mehr wissen Sie, wie der Code organisiert werden muss und wo Sie nach Antworten auf bestimmte Fragen suchen können. Einige Codes sind etwas schwieriger zu befolgen, insbesondere wenn sie ziemlich indirekt sind. Deshalb brauchst du Bleistift und Papier. Irgendwann geht eine Glühbirne in deinem Kopf aus und du bekommst es. Dann macht das Lesen des restlichen Codes viel mehr Sinn.
Es liest sich nicht so, wie Sie einen Roman lesen, sondern wie Sie ein Nachschlagewerk lesen. Eine gute Möglichkeit besteht darin, einen kürzlich behobenen Fehler in einer Check-in-Nachricht zu suchen, Änderungen vorzunehmen und die relevanten Teile zu lesen, bis Sie sowohl das Problem als auch die Lösung verstanden haben. Bekannt gewordene Sicherheitslücken machen Spaß, da in den Foren viel darüber diskutiert wird. Wählen Sie dann einen der "niedrig hängenden Früchte" -Fehler aus dem Bug-Tracker aus und lesen Sie, bis Sie wissen, wie Sie ihn selbst beheben können. Die meisten Codelesefachleute sind zufällig dabei, Fehler zu beheben oder Funktionen hinzuzufügen.
Normalerweise sind die besten Codebeispiele kaum zu bemerken. Sie werden sie sofort verstehen, ohne sie mehr als einmal durchzulesen. Sie lassen es so aussehen, als sei es extrem einfach zu schreiben, obwohl Code, der gut ist, normalerweise viele Entwürfe durchläuft. Es entsteht das paradoxe Gefühl, dass natürlich der gegebene Code der offensichtliche Weg ist, dies zu tun, obwohl es nicht der erste Weg ist, an den Sie gedacht haben.
Wenn Sie auf Code wie diesen stoßen, versuchen Sie, die Erkenntnisse, die beim Schreiben des Codes gewonnen wurden, und die damit verbundenen Gestaltungsprinzipien zu verstehen. Wenn Sie sich also in Zukunft in einer ähnlichen Situation befinden, können Sie hoffentlich dieselben Prinzipien anwenden.
Ein Trick, den ich beim Lesen einer komplizierten Funktion ziemlich oft benutze, ist, das Code-Segment in etwas lesbareres umzugestalten, ohne die Logik zu ändern.
Wie ist es schwierig mit "ein paar Dateien" umzugehen? Es unterscheidet sich nicht von dem Zeitpunkt, zu dem Sie Ihren eigenen Code schreiben, es sei denn, Sie haben zuvor keine Kenntnisse über dessen Organisation, es sei denn, dies ist dokumentiert.
Wenn Sie als behaupteter Programmierer die Projektstruktur nicht aus "einer Reihe von Dateien" herausfinden können, ist dies entweder ein äußerst schlecht organisiertes Projekt oder Sie sind ein unfähiger Programmierer (oder in extremen Fällen beides).
Beginnen Sie mit dem Lesen, versuchen Sie, einige Einstiegspunkte oder andere wichtige Pivot-Klassen / Methoden zu finden, und verstehen Sie, wie alles von dort aus zusammenkommt. Wird nicht sofort sein, wird einige Zeit in Anspruch nehmen, kann aber durchgeführt werden, auch wenn überhaupt keine Dokumentation vorhanden ist.
Das Beste, worauf Sie beim Lesen des Codes eines anderen Projekts hoffen können, sei es eine API oder Software, ist, dass die Variablen, Funktionen und Makronamen nicht mehrdeutig abgekürzt oder benannt werden, damit Sie ihre Absicht herausfinden können.
Davon abgesehen ist jedoch eine angemessene Menge an Kenntnissen erforderlich, die über die Sprache, die Programmiertechniken und auch über den eigentlichen Zweck des Codes verteilt sind, um in komplexen Code eintauchen zu können.
Ich versuche gerade zu sehen, wie Lua etwas von seiner Magie macht, aber ich komme zu dem Punkt, an dem viele der Bezeichner vage benannt und eher abgekürzt sind, bis zu dem Punkt, an dem ich nicht herausfinden kann, welche Linie es versucht Das, was ich weiß, muss irgendwann im Funktionscode erledigt werden ... Die häufigen Einzelbuchstabenvariablen und die eher abgekürzten Makro- / Funktionsnamen tun mir weh.
Nach dem Blick auf "Beginnen Sie zuerst auf hoher Ebene aus der Vogelperspektive", wie @Berin Loritsch es vorschlug, können Sie nach Unittests und / oder Integrationstests suchen, falls es welche gibt.
unittests sind interessant zu sehen, wie (api-) details funktionieren.
Der Integrationstest gibt in der Regel einen guten Überblick über die Geschäftsprozesse.