Quali strumenti o tecniche sono utili per descrivere una base di codice non familiare? [chiuso]

Quando ispeziono manualmente un codice sconosciuto (da rivedere o modificare), mi sembra di avere tre opzioni.

• Una lettura dall'alto verso il basso del codice, scegliendo ogni prossimo file sorgente in base a quanto fondamentale appare il nome del file. Di solito finisco per leggere quasi tutto. Alcuni file due volte.
• Una prima lettura , in cui trovo e leggo tutto il metodo di invocazione con una comprensione minima. Quindi leggi tutte le funzioni chiamate dalla funzione e così via. Il mio stack mentale tende a traboccare se faccio qualche chiamata in profondità.
• Una prima lettura approfondita , in cui passo attraverso tutto il codice in un debugger, incerto se ciò richiederà 8 minuti o 8 ore.

Una volta che ho letto abbastanza del codice per avere una comprensione abbastanza solida di ciò che sta facendo, spesso rifletto di aver letto l'80% o più della base di codice, mentre il codice fondamentale è del 20% o meno . Ho perso molto tempo.

Quali strumenti sono utili per ottenere una rapida comprensione di codice non familiare? Esistono strumenti in grado di fornire una "visione d'insieme" del percorso del codice critico e che mi consenta di approfondire i dettagli di una parte?

La cosa migliore, ovviamente, è che qualcuno che conosce la base di codice vi guidi. Se questa non è un'opzione, allora ci sono alcuni strumenti che possono aiutarti.

• VisualStudio può generare automaticamente un diagramma di classe UML di una base di codice. Per lo meno ti mostrerà le gerarchie di classi.
• Doxygen può essere estremamente utile. Anche se il codice non ha commenti in stile doxygen, doxygen può comunque generare documentazione leggibile, diagrammi di classe e grafici di chiamata, che può essere molto utile per orientarsi in una base di codice non familiare.

In genere, si desidera utilizzare anche un IDE completo, in cui è possibile fare clic con il pulsante destro del mouse su qualsiasi cosa e "passare alla definizione". Questo può farti risparmiare un sacco di tempo, rispetto all'utilizzo di grep su molti file in una struttura di directory complessa.

Un'altra cosa importante, a seconda di quanto tempo dovrai gestire il codice. Se ci sono test unitari, guarda attraverso i test. Se non ci sono test, inizia a scriverli. Formulare un'ipotesi su ciò che fa una particolare classe o funzione e scrivere un test per testarlo. Questo richiede molta disciplina, ma è un ottimo modo per ottenere risposte su ciò che sta accadendo nel codice.

Questo è un approccio più drastico. Questa tecnica può essere utile per un progetto che ha molte classi che non sono organizzate in spazi dei nomi significativi.

L'obiettivo di questo esercizio è scoprire la relazione di classe. Crea un clone usa e getta del progetto, quindi prova a inserire alcune classi negli spazi dei nomi. Per risparmiare tempo su ripetuti tentativi, utilizzare alcuni strumenti di elaborazione dei file Regex per automatizzare questa modifica.

Ciò causerà molti errori del compilatore. Nel processo di correzione di questi errori, si avrà una migliore comprensione del modo in cui queste classi dipendono l'una dall'altra e si deciderà quali classi possono essere inserite nello stesso spazio dei nomi.

Questa tecnica è utile in quanto si può applicare anche con una scarsa comprensione dell'organizzazione del codice del progetto. Da ciò deriva il rischio che alcune classi possano essere smarrite da questa tecnica a causa di incomprensioni.