Quelles sont les bonnes techniques pour conserver sa place dans le code?

Je comprends l'utilisation de signets pour mémoriser un seul point de votre code. Cependant, comment suivre le flux du code sur lequel ils enquêtent? Par exemple: plusieurs signets et l'ordre dans lequel ils ont été créés.

Exemple:

1. Rapport de bug: "Les collisions ne fonctionnent pas aux coins des murs"

   1. La reproduction du bogue le réduit à certains polygones qui n'entrent pas en collision.
   2. Le code de collision a été écrit par un développeur non disponible. L'enquête va donc quelque chose comme:

Au cours de l'enquête, en particulier lors de l'examen d'éléments non codés tels que Google, on peut raisonnablement s'attendre à ce que l'on perde leur place dans le code ( ai-je déjà examiné ce chemin de code? Ou quel chemin de code recherchais-je? Il y en a plusieurs qui mènent à cette fonction , etc.). Il en va de même pour les interruptions inévitables (Boss: j'ai besoin de [Long Pointless Report] MAINTENANT , etc.)

Il serait utile d'avoir une ressource de techniques ou d'outils pour fournir un moyen de garder une trace de sa place dans le code.

Modifier : l'exemple ci-dessus est conçu comme une illustration potentielle, pas comme un problème réel qui nécessite une réponse.

Une autre façon de formuler cette question est:

Lorsque vous apprenez un nouveau système, comment pouvez-vous savoir où vous en êtes dans l'apprentissage du code? Il ne s'agit pas de comprendre pourquoi le code fait ce qu'il fait (ce à quoi devraient servir les commentaires), mais comment il le fait (ce qui n'est appris qu'en lisant le code, pas les commentaires).

L'interface de bulles tente de résoudre ce problème en affichant un tas de bits de code à la fois. (Vous êtes coincé avec votre navigateur pour Google). Ça a l'air incroyable mais je ne l'ai pas essayé. Cette version de l'idée est une implémentation de Visual Studio pour Visual Studio Ultimate.

Mis à part toutes les grandes technologies mentionnées, j'ai trouvé que le morceau de papier A3 à l'ancienne est une excellente aide dans ces problèmes. Notez vos idées et organisez-les sous forme de carte mentale.

Mon éditeur et mon débogueur peuvent tous deux accéder à la définition d'une fonction et avoir un bouton "retour" à plusieurs niveaux comme un navigateur Web pour revenir là où j'étais auparavant. Cela me suffit généralement pour suivre un flux de débogage complexe. Cela permet également d'avoir un contrôle de source qui vous permet de vous engager beaucoup . Cela me donne un message de validation expliquant pourquoi j'essaye quelque chose, ainsi qu'un moyen rapide d'annuler le changement si cela ne fonctionne pas. En dehors de cela, un simple tableau blanc pour répertorier les pistes potentielles et explorées comble toutes les lacunes restantes pour moi.

Plusieurs façons dont je garde la trace:

• Écrivez-le . Vous avez une réunion en deux minutes? Notez ce que vous faisiez et où. J'ai toujours un stylo et du papier à côté de moi pour écrire des choses pendant que je code.
• Signets . J'ai 10 signets numérotés que je peux définir.
• Stacktrace . Vous pouvez facilement afficher toute la hiérarchie de code que vous avez parcourue. Mon éditeur me permet également de copier la trace de la pile et de l'enregistrer. La prochaine fois que j'ouvrirai mon éditeur, je pourrai charger le stacktrace pour une navigation rapide.
• Navigation de l'éditeur . Aller au membre de base, aller à l'héritier, trouver les usages, aller à la référence, ...

J'utilise la solution simple - ne fermez jamais rien tant que je n'ai pas terminé la tâche. Cela signifie que généralement l'une des quelque 50 fenêtres / onglets ouverts contient quelque chose qui me rappellera ce que je pensais quand j'y reviendrai.

Obtenez un véritable outil de développement / IDE, ce qui vous fait envie. Vi, Emacs, Eclipse ou autre (le choix est aussi grand que les arguments sur lequel est le meilleur, mais c'est un autre problème), et apprenez à l'utiliser correctement . ne le faites pas, comme beaucoup le font, comme le Bloc-notes avec la coloration syntaxique. Apprenez à utiliser les raccourcis clavier et à ne pas vous fier à la souris pour les actions courantes (c'est trop lent). Un grand écran (1920x1200 minimum) est bénéfique.

Mon outil de développement a nommé (des noms plus lents mais utiles les rendent persistants) et des signets sans nom (rapide à insérer et à supprimer), une navigation avant et arrière et une recherche de référence tout en un, des tâches et des notes de développeur (personnelles et du groupe) attachées à un ligne particulière de code source. Il fait toutes les langues sous le soleil, sans avoir à installer encore un autre plugin.

Je travaille sur une base de code composée d'une douzaine ou plus de 1 million de modules SLOC, en utilisant une demi-douzaine de langues. Évidemment, je ne travaille pas sur chacun d'eux à la fois, je me concentre plutôt sur de petites parties d'un ou deux, mais je peux naviguer avec quelques actions à n'importe quel point du code qui se rapporte à ce que je fais.

Avec Visual Studio, dans une session de débogage, vous pouvez utiliser la fenêtre 'Call Stack' (vous pouvez l'activer dans Debug / Windows / Call Stackou avec le raccourci Ctrl+Alt+c) pour suivre le flux de code.

Je suis surpris que personne n'ait mentionné les nombreux outils qui peuvent créer des diagrammes d'appels. J'ai trouvé que le doxygène était d'une grande aide. Vous n'avez même pas à vous engager à utiliser doxygen tout au long de votre programme, vous pouvez simplement baliser les fonctions que vous souhaitez tracer.

J'utilise le mode org pour emacs, qui est un outil uber-contour. Avec lui, je peux écrire un plan qui imite la pile d'appels du code et inclure des liens directs vers le code source lui-même (via org-store-link). Vous pouvez inclure du texte explicatif, des liens vers des pages Web, etc. (par exemple lorsque vous recherchez des nombres magiques sur Google)

Ce n'est pas parfait. Par exemple, la structure hiérarchique n'a aucune idée de remonter un niveau, il est donc difficile de tracer un chemin d'exécution, par opposition à une simple pile. Mais c'est la meilleure chose à côté des diagrammes sur papier que j'ai trouvé.