Quali sono le buone tecniche per mantenere il tuo posto nel codice?

Comprendo l'utilizzo dei segnalibri per ricordare un singolo punto del codice. Tuttavia, come si può tenere traccia del flusso del codice che stanno esaminando? Ad esempio: più segnalibri e l'ordine in cui sono stati creati.

Esempio:

1. Segnalazione bug: "Le collisioni non funzionano agli angoli dei muri"

   1. La riproduzione del bug lo riduce ad alcuni poligoni che non si scontrano.
   2. Il codice di collisione è stato scritto da un sviluppatore non disponibile. Quindi le indagini vanno in qualche modo:

Durante l'indagine, in particolare quando si esaminano elementi non di codice come Google, ci si può ragionevolmente aspettare che perdano il loro posto nel codice ( ho già esaminato questo percorso di codice? O quale percorso di codice ho esaminato? Ci sono più che conducono a questa funzione , ecc.). Lo stesso vale per inevitabili interruzioni (Boss: ho bisogno di [Rapporto inutile lungo] ORA , ecc.)

Sarebbe utile disporre di una risorsa di tecniche o strumenti per fornire un modo per tenere traccia della propria posizione nel codice.

Modifica : l'esempio sopra è inteso come una potenziale illustrazione, non come un problema reale che deve essere risolto.

Un altro modo per formulare questa domanda è:

Quando apprendi un nuovo sistema, come tieni traccia di dove stai imparando il codice? Non si tratta di capire perché il codice fa quello che fa (che è ciò a cui dovrebbero essere i commenti), ma come lo fa (che viene appreso solo leggendo il codice, non i commenti).

L'interfaccia bolle tenta di risolvere questo problema mostrando un sacco di bit di codice contemporaneamente. (Sei bloccato con il tuo browser per Google). Sembra incredibile ma non l'ho provato. Questa versione dell'idea è un'implementazione di Visual Studio per Visual Studio Ultimate.

A parte tutte le grandi tecnologie menzionate, ho scoperto che il vecchio pezzo di carta A3 è di grande aiuto in questi problemi. Scrivi le tue idee e organizzale in stile mindmap.

Sia il mio editor che il debugger possono passare alla definizione di una funzione e avere un pulsante "indietro" multilivello come un browser Web per tornare dove ero prima. Di solito è sufficiente per me tenere traccia di un flusso di debug complesso. Aiuta anche ad avere il controllo del codice sorgente che ti consente di impegnarti molto . Questo mi dà un messaggio di commit che spiega perché sto provando qualcosa, oltre a un modo rapido per annullare la modifica se non funziona. Oltre a ciò, una semplice lavagna per elencare i potenziali ed esplorati lead riempie per me eventuali lacune rimanenti.

Molteplici modi in cui tengo traccia:

• Scrivilo . Hai una riunione tra due minuti? Scrivi cosa stavi facendo e dove. Ho sempre carta e penna accanto a me per annotare le cose mentre scrivo.
• Segnalibri . Ho 10 segnalibri numerati che posso impostare.
• Stacktrace . Puoi facilmente visualizzare l'intera gerarchia di codice che hai attraversato. Il mio editor mi consente anche di copiare la traccia dello stack e salvarla. La prossima volta che apro il mio editor, posso caricare lo stacktrace per una navigazione veloce.
• Navigatore dell'editor . Vai al membro di base, vai all'erede, trova gli usi, vai al riferimento, ...

Uso la soluzione semplice: non chiudere mai nulla fino a quando non ho terminato l'attività. Ciò significa che di solito una delle 50 finestre / schede aperte contiene qualcosa che mi ricorderà cosa stavo pensando quando torno ad esso.

Ottieni un vero strumento di sviluppo / IDE, tutto ciò che ti appassiona. Vi, Emacs, Eclipse o qualsiasi altra cosa (la scelta è ampia quanto le argomentazioni su quale sia la migliore, ma che è un altro problema), e impara ad usarla correttamente . non, come troppi fanno, usalo come Blocco note con l'evidenziazione della sintassi. Impara a usare i tasti di scelta rapida e non fare affidamento sul mouse per azioni comuni (è troppo lento). Un grande schermo (minimo 1920x1200) è benevolo.

Il mio strumento di sviluppo ha nomi (nomi più lenti ma utili che li rendono persistenti) e senza nome (Inserimento rapido ed eliminazione) segnalibri, navigazione avanti e indietro e ricerca di riferimenti tutti in uno, todo e note per sviluppatori (personali e di gruppo) associate a un particolare riga del codice sorgente. Fa tutte le lingue sotto il sole, senza dover installare ancora un altro plugin.

Lavoro su una base di codice composta da una dozzina o più di 1 milione più moduli SLOC, usando una mezza dozzina di lingue. Ovviamente non lavoro su tutti alla volta, piuttosto mi concentro su piccole parti di una o due, ma posso navigare con alcune azioni verso qualsiasi punto del codice che è relativo a ciò che sto facendo.

Con Visual Studio, in una sessione di debug, è possibile utilizzare la finestra "Call Stack" (è possibile abilitarla nel Debug / Windows / Call Stacko con il collegamento Ctrl+Alt+c) per tenere traccia del flusso di codice.

Sono sorpreso che nessuno abbia menzionato i numerosi strumenti che possono creare grafici di call call. Ho trovato doxygen per essere di grande aiuto. Non devi nemmeno impegnarti a utilizzare doxygen in tutto il programma, puoi semplicemente taggare le funzioni che ti interessano.

Uso la modalità org per emacs, che è uno strumento estremamente utile. Con esso, posso scrivere uno schema che imita lo stack di chiamate del codice e includere collegamenti diretti al codice sorgente stesso (tramite org-store-link). È possibile includere testo esplicativo, collegamenti a pagine Web, ecc. (Ad es. Quando si cerca su Google numeri magici)

Non è perfetto Ad esempio, la struttura del contorno non ha alcuna idea di tornare indietro di un livello, quindi è difficile tracciare un percorso di esecuzione, al contrario di un semplice stack. Ma è la prossima cosa migliore per i diagrammi su carta che ho trovato.