A volte prima di sviluppare nuovi prodotti dobbiamo comprendere alcuni prodotti esistenti o il codice sorgente esistente.
A volte per scrivere un altro piccolo modulo di quel grande progetto abbiamo bisogno di capire quel grande codice sorgente.
Nel nostro caso dobbiamo studiare e capire un progetto con molti file e cartelle. Qual è il modo più semplice e comodo per farlo? (specialmente per C e C ++ e sotto Linux)
Tutti i grandi progetti hanno una sorta di documentazione di solito Doxygen che può aiutare molto nella comprensione del codice.
Puoi anche utilizzare strumenti di esplorazione del codice come SourceInsight per studiare il codice.
Ultimo ma l'approccio migliore è eseguire il codice e utilizzare i casi di debug.
Als ha già menzionato doxygen che viene utilizzato per la documentazione in molti progetti.
Per la navigazione di origine: vim insieme ai plugin, cscope & ctags funzionano molto bene. Questi possono essere installati facilmente su ambiente Linux e funzionano molto bene in tandem.
Spero che questo ti aiuti!
Ci sono diversi approcci. La documentazione, se presente, dovrebbe aiutare, ma nel mondo reale ci sono purtroppo molte basi di codice scarsamente documentate. In molti casi puoi chiedere ad alcuni sviluppatori senior della società di fornire indicazioni, assicurati di chiedere una vista di alto livello su cosa e come sono fatte le cose in ogni modulo.
Puoi usare uno strumento di analisi UML per estrarre informazioni dalla base di codice, suggerisco BoUML, non è bello, ma fa un buon lavoro nell'elaborare C ++, e puoi creare diagrammi di classe semplicemente tirando una classe ed espandendo da lì.
Anche un IDE o un set di strumenti simile che ti aiuti a navigare attraverso il codice ti aiuterà, in quanto ti permetteranno di navigare attraverso il codice molto più facilmente che con un semplice editor.
Mentre fai le analisi, assicurati di prendere appunti su ciò che credi che faccia ogni parte del codice, o in caso di dubbi, quindi chiedi a un anziano della compagnia di confermare le tue intese o di colmare le lacune.
Mentre la lettura e la documentazione possono essere utili, anche la scrittura aiuta!
Scrivi alcuni test (niente di serio) che utilizzino le funzionalità comuni del codebase, o concentrati sui componenti che dovrai utilizzare.
Prova a documentare alcune delle cose che non ti aspettavi, i problemi che avevi e le deviazioni dalle pratiche del tuo team.
Potresti essere sorpreso dal modo in cui alcuni programmi funzionano e da come dovrebbero essere usati.
Hai solo bisogno di un duro lavoro.
Familiarizzare con una base di codice di grandi dimensioni è come districare una matassa. Inizi da qualche parte, non capisci niente. Quindi ricomincia da capo, non capisci nulla.
Inizia dopo l'inizio, alcune parti diventano meno oscure. Ripartire da dove hai iniziato la prima volta ora fornisce alcuni indizi.
Quindi la strategia è dividere e conquistare. Isolare i moduli e comprenderli uno dopo l'altro.
Gli inizi possibili sono: Makefile, funzione main (), gerarchia di file, documentazione esistente (almeno un file README) o qualsiasi cosa Doxygen sia in grado di estrarre anche se non era pianificata.
Leggi altre domande sui tag open-source c++ c linux