Was sind gute Techniken, um Ihren Platz im Code zu behalten?

Ich verstehe, Lesezeichen zu verwenden, um sich an einen einzelnen Punkt in Ihrem Code zu erinnern. Wie kann man jedoch den Fluss des Codes verfolgen, den sie untersuchen? ZB: mehrere Lesezeichen und die Reihenfolge, in der sie erstellt wurden.

Beispiel:

1. Fehlerbericht: "Kollisionen funktionieren nicht an den Ecken von Wänden"

   1. Die Reproduktion des Fehlers führt dazu, dass bestimmte Polygone nicht kollidieren.
   2. Der Kollisionscode wurde von einem nicht verfügbaren Entwickler geschrieben. Die Untersuchung sieht also so aus:

Im Verlauf der Untersuchung, vor allem , wenn nicht-Code Elemente wie Google bewerten, kann man vernünftigerweise erwarten, ihren Platz im Code zu verlieren ( Habe ich bereits an diesem Codepfad geschaut? Oder Welchen Codepfad untersuchte ich? Es mehrere ist , dass Blei zu dieser Funktion etc). Das Gleiche gilt für unvermeidbare Unterbrechungen (Boss: Ich brauche JETZT [langwierigen, sinnlosen Bericht] usw.)

Es wäre nützlich, eine Ressource mit Techniken oder Werkzeugen zur Verfügung zu haben, mit denen man seinen Platz im Code nachverfolgen kann.

Bearbeiten : Das obige Beispiel ist als mögliche Illustration gedacht, nicht als tatsächliches Problem, das beantwortet werden muss.

Eine andere Möglichkeit, diese Frage zu formulieren, ist:

Wie behalten Sie beim Erlernen eines neuen Systems den Überblick, wo Sie sich mit dem Erlernen des Codes beschäftigen? Es geht nicht darum zu verstehen, warum der Code das tut, was er tut (wofür Kommentare sein sollten), sondern darum , wie er es tut (was nur durch Lesen des Codes gelernt wird, nicht durch Kommentare).

Die Bubbles-Schnittstelle versucht, dieses Problem zu lösen, indem eine Reihe von Codebits gleichzeitig angezeigt werden. (Sie sind mit Ihrem Browser für das Googeln fest). Es sieht toll aus, aber ich habe es nicht ausprobiert. Diese Version der Idee ist eine Visual Studio-Implementierung für Visual Studio Ultimate.

Abgesehen von all den großartigen erwähnten Technologien habe ich festgestellt, dass das altmodische A3-Stück Papier eine hervorragende Hilfe bei diesen Problemen ist. Schreiben Sie Ihre Ideen auf und organisieren Sie sie im Mindmap-Stil.

Sowohl mein Editor als auch mein Debugger können zu einer Funktionsdefinition springen und haben eine mehrstufige "Zurück" -Schaltfläche wie ein Webbrowser, um dorthin zurückzukehren, wo ich vorher war. Das reicht normalerweise aus, um einen komplexen Debugging-Ablauf zu verfolgen. Es ist auch hilfreich, eine Quellcodeverwaltung zu haben, mit der Sie eine Menge festlegen können . Das gibt mir eine Commit-Nachricht, in der erklärt wird, warum ich etwas versuche, und eine schnelle Möglichkeit, die Änderung rückgängig zu machen, wenn sie nicht funktioniert. Abgesehen davon füllt ein einfaches Whiteboard, an dem potenzielle und erkundete Leads aufgelistet werden, die verbleibenden Lücken für mich.

Mehrere Möglichkeiten, die ich verfolge:

• Schreib es auf . In zwei Minuten ein Meeting? Schreiben Sie auf, was Sie getan haben und wo. Ich habe immer Stift und Papier neben mir, um Dinge aufzuschreiben, während ich programmiere.
• Lesezeichen . Ich habe 10 nummerierte Lesezeichen, die ich setzen kann.
• Stacktrace . Sie können ganz einfach die gesamte Code-Hierarchie anzeigen, die Sie durchlaufen haben. Mit meinem Editor kann ich auch den Stack-Trace kopieren und speichern. Wenn ich das nächste Mal meinen Editor öffne, kann ich den Stacktrace für eine schnelle Navigation laden.
• Editor-Navigation . Gehen Sie zum Basismitglied, gehen Sie zum Erben, finden Sie Verwendungen, gehen Sie zum Verweis, ...

Ich benutze die einfache Lösung - schließe nie etwas, bis ich mit der Aufgabe fertig bin. Das bedeutet, dass normalerweise eines der rund 50 geöffneten Fenster / Registerkarten etwas enthält, das mich daran erinnert, was ich dachte, als ich darauf zurückkam.

Holen Sie sich ein echtes Entwicklertool / IDE, was immer Sie möchten. Vi, Emacs, Eclipse oder was auch immer (Die Auswahl ist so groß wie die Argumente, über die am besten ist, aber das ist ein weiteres Problem), und lernen, es richtig zu verwenden . Verwenden Sie es nicht, wie es zu viele tun, wie Notepad mit hervorgehobener Syntax. Lernen Sie, wie man Hotkeys verwendet, und verlassen Sie sich nicht auf die Maus, um allgemeine Aktionen auszuführen (es ist zu langsam). Ein großer Bildschirm (mindestens 1920 x 1200) ist von Vorteil.

Mein Entwicklertool hat benannte (langsamere, aber nützliche Namen machen sie dauerhaft) und unbenannte (schnelles Einfügen und Löschen) Lesezeichen, vorwärts- und rückwärtssuchen und Referenzsuche in einem, Aufgaben- und Entwicklernotizen (persönlich und gruppenweit), die an a angehängt sind bestimmte Zeile des Quellcodes. Es macht jede Sprache unter der Sonne, ohne noch ein Plugin installieren zu müssen.

Ich arbeite auf einer Codebasis, die aus einem Dutzend oder mehr 1 Million plus SLOC-Modulen besteht und ein halbes Dutzend Sprachen verwendet. Natürlich arbeite ich nicht an allen gleichzeitig, sondern konzentriere mich auf kleine Teile von einem oder zwei, aber ich kann mit ein paar Aktionen zu jedem Punkt im Code navigieren, der für das, was ich tue, relevant ist.

Mit Visual Studio können Sie in einer Debugsitzung das Fenster "Aufrufliste" (Sie können es in Debug / Windows / Call Stackoder mit der Verknüpfung aktivieren) verwenden, um den Codefluss Ctrl+Alt+czu verfolgen.

Ich bin überrascht, dass niemand die vielen Tools erwähnt hat, mit denen Diagramme mit Anrufgrafiken erstellt werden können. Ich habe gefunden, dass Sauerstoff eine große Hilfe ist. Sie müssen sich nicht einmal für die Verwendung von Doxygen in Ihrem gesamten Programm verpflichten, sondern können einfach die Funktionen markieren, die Sie für die Verfolgung interessieren.

Ich benutze den Org-Modus für Emacs, ein Tool, das alles umreißt. Damit kann ich eine Gliederung schreiben, die den Aufrufstapel des Codes nachahmt und direkte Links zum Quellcode selbst enthält (via org-store-link). Sie können erläuternden Text, Links zu Webseiten usw. einfügen (z. B. wenn Sie nach magischen Zahlen googeln).

Es ist nicht perfekt. Zum Beispiel hat die Gliederungsstruktur keine Ahnung, dass sie eine Ebene höher gehen soll, daher ist es schwierig, einen Ausführungspfad zu verfolgen, anstatt nur einen Stapel. Aber es ist das zweitbeste, was ich für Diagramme auf Papier gefunden habe.