Come leggere migliaia di righe di codice senza alcuna documentazione? [chiuso]

In precedenza ero alla ricerca di un buon controllo TimeLine per un progetto WPF. Ho trovato una risposta qui che mi indirizza a questo progetto CodePlex .

Ora voglio cambiare il codice per soddisfare le mie esigenze di cultura. Ma ci sono alcune discrepanze!

La mia domanda è:

Come interagisci con tali migliaia di righe di codice?

MODIFICARE:

Qualsiasi scorciatoia sarà fantastica!

Aggiungi commenti al codice sorgente quando hai capito abbastanza per poterlo fare. Rifattorizza vigorosamente questi commenti man mano che capisci sempre di più.

1. Scorri il codice
2. Rinomina secondo necessità
3. Rifrattore secondo necessità
4. Ripeti fino a quando non capisci completamente

... e il codice ti ringrazierà per questo. ;-)

Esegui una singola azione, esegui il debug (ancora e ancora) del codice per scoprire come tale azione viene eseguita. Scrivi lo stesso in un linguaggio semplice per capire meglio!

Qualcosa che Joel Spolsky ha scritto molto tempo fa quando era sul suo blog (non riesco a trovare l'articolo ora) davvero bloccato con me riguardo a questo:

Ha detto che il codice non è un linguaggio umano naturale, ma come programmatori, siamo facilmente indotti a pensare che lo sia e che dovremmo essere in grado di leggerlo come tale. Di conseguenza, molti di noi guardano il nuovo codice e si aspettano di essere in grado di "leggerlo" e comprenderlo immediatamente, come se fosse un blocco di testo in inglese.

Quindi penso che la chiave sia fondamentalmente essere lenti, metodici e scientifici. E come altri hanno già detto, commentalo (e persino rifattore) mentre procedi. Non cadere nella mentalità di "Dovrei solo guardarlo e capire immediatamente".

Oh, e sì, a volte cado ancora in questa trappola a volte. "Fai come dico, non come faccio", e tutto il resto. :)

SE-Radio ha intervistato Dave Thomas proprio su questo argomento

Questo episodio di podcast ha molti suggerimenti e tecniche per entrare nella "cultura" del progetto e capire come vivevano gli abitanti originali.

Ho dovuto farlo di recente con un progetto di oltre 100.000 LOC. La mia prima idea è stata che è più facile vedere schemi da grafici di 100 o persino 1000 nodi che da 100.000 righe di testo.

Quindi ho trascorso 45 minuti e ho scritto un breve programma (<100LOC) Python per analizzare ciò di cui avevo bisogno e disegnare le relazioni dell'oggetto. Ho generato la fonte Graphviz , che è un linguaggio davvero facile da generare. (Non c'è niente di speciale in Python qui: Ruby o C # o Common Lisp o qualunque cosa possa farlo altrettanto bene.)

In altri progetti, ho visto le persone usare Graphviz per dipendenze dei moduli, grafici delle chiamate, cronologia delle versioni, cose di ogni genere. Il più grande meta-strumento per la visualizzazione dei programmi di sempre.

(Forse è perché ho preso i compilatori , ma trovo strano che quando un programmatore si trova ad affrontare un problema, la risposta sembra essere sempre "scrivere un programma!", Tranne quando il problema riguarda il codice sorgente di un programma.: - )

Passalo attraverso il debugger mentre è in esecuzione, è quasi l'unico modo per capire una nuova base di codice di grandi dimensioni.

Comprendi che non ci sono scorciatoie per il trekking in pienezza. (E se hai problemi con quella frase, la tua educazione è stata MOLTO trascurata. Viene da "Stranger In a Strange Land", di Robert A. Heinlein.)

Leggilo, una pagina alla volta, una routine alla volta. Aggiungi commenti. Disegna immagini delle principali strutture di dati. Riconosci gli algoritmi. Attingi da conoscenze precedenti.

Resistere alla tentazione di avviare il debugger. La vista del debugger è troppo piccola: vedi una riga alla volta, ma in realtà non vedi dove sei stato o dove stai andando.

Qualunque cosa tu faccia, scrivi più che puoi, così nessuno finirà mai nella stessa posizione che hai.

devi usare indizi. ottenere un indizio di ciò che si deve cercare e utilizzare ampiamente la funzionalità di ricerca del proprio ambiente o IDE che può portarti nella sezione desiderata del codice che è necessario apportare modifiche.

leggere 14 mila righe di codice java non ha alcun senso. La funzionalità di ricerca ti salva la vita

Persone diverse hanno stili di apprendimento diversi, quindi YMMV. La prima cosa che faccio in questa situazione è leggere l'intera base di codice almeno una volta. Questo mi dà un'idea generale di dove sia tutto. Quindi scelgo una sezione da esaminare in modo più dettagliato. Le strutture dati sarebbero un buon punto di partenza. Una volta che ho un'idea generale di cosa sta succedendo, faccio lo stesso con un'altra parte del codice che interagisce con il primo. Dopo abbastanza iterazioni, ho una buona idea di come funziona il codice.

Il modo migliore, come con tutta la programmazione non solo grossi pezzi di codice non commentato, è di scomporlo in pezzi. Questo è sia qualcosa che dovresti fare nella tua testa sia visivamente nel codice. Ciò può significare l'aggiunta di grandi commenti in grassetto o più interruzioni di riga. Questo aiuta mentre lo scorri per vedere i pezzi. Prova a trovare i blocchi logici di codice.

Ovviamente, mentre capisci i bit, commentali per quello che sai in quel momento, eventualmente inserendo note su qualcosa che non capisci.

Consiglierei anche di non provare a capire l'intero pezzo fin dall'inizio. Invece cerca di capire i pezzi che devi sapere in questo momento e di lavorare sul resto in seguito.

Vorrei iniziare usando l' Editor Leo in modalità @shadow con l'uso attivo dei nodi clonati . Ciò consente di aggiungere note e commenti per ogni sezione di codice in studio senza modificare il codice e le annotazioni saranno sempre nel contesto, accanto al codice di cui sta parlando. Ecco un flusso di lavoro di esempio i documenti:

Ad esempio, quando correggo un bug in Leo, creo un nodo normale per rappresentare il bug. Questo nodo di bug è la mia visione di tutti i dati nel codice sorgente di Leo relativi al bug. Quando scopro il codice relativo al bug, clonano i loro nodi e li sposto sotto il nodo del bug. Aggiungerò anche nodi ordinari come figli del nodo bug. Questi nodi contengono la segnalazione di bug originale, le descrizioni di come ho corretto il bug, i dati di test o qualsiasi altra nota che potrei voler conservare.

Una volta creato il nodo bug, mi concentro solo su quel nodo e sui suoi figli. Posso esaminare il nodo bug e i suoi figli senza dover saltare il contorno. Tutto ciò di cui ho bisogno è in un unico posto. Quando riesco a risolvere il problema, posso farlo cambiando i cloni. Ancora una volta, non devo saltare il contorno. Non importa quanto sia grande o complessa l'intera struttura: ho a che fare solo con il nodo bug e i suoi figli. Questa messa a fuoco estremamente ristretta rende molto più facile correggere i bug.

Disegna diagrammi della fonte: le relazioni di dati, le relazioni funzionali, le relazioni di oggetti. Determinare l'aggregazione, il flusso di dati e il flusso di codice. Le immagini sono molto meglio dei commenti per questo, e possono essere tenute separate dal codice.

Prima di refactificare qualsiasi cosa scrivere test. Molti test. Test molto specifici su piccoli blocchi di codice che sono almeno richiamabili, poiché dipenderà da come viene scritto il tuo pasticcio ereditato.

Il vantaggio di scrivere i test per cominciare è che devi avere una qualche comprensione del codice prima di poterlo testare, quindi ogni test che scrivi sarà un po 'di conoscenza acquisita. Puoi anche commentare pesantemente i test con le tue assunzioni insieme alle asserzioni.

Effettuando prima il test, non corri il rischio di alterare qualcosa nel codice che ha effetti a catena che non puoi conoscere. Avrai anche una rete di sicurezza quando verrai a riformattare il codice.

Uso strumenti come doxygen, per generare un diagramma di classe generale, che aggiunge la mia comprensione di ciò che ciascuna classe fa.

Quindi raccolgo alcuni semplici bug dalla coda dei bug (prima che il mio manager ne assegni uno difficile: P), quindi eseguo quella funzionalità nel debugger e provo a generare un flusso di dati approssimativo o un modello di flusso di codice.

Ad esempio funzionalità di esportazione in alcuni software: quindi cerco di capire come vengono letti i dati di origine, da dove nel codice (interfaccia di base) posso valutare che i dati vengano letti correttamente usando i miei diagrammi di flusso di classe e di codice, di quali classi sono responsabili quale tipo di esportazioni, ecc. Penso che metà della comprensione sia fatta, una volta che hai i diagrammi di classe e i diagrammi di flusso.

Affronta un difetto insignificante, ad esempio una NullPointerException. Per prima cosa evita qualsiasi cosa riguardante la concorrenza, qualsiasi cosa che per sua natura comporterà la comprensione di molto codice contemporaneamente.

Dopo aver corretto alcuni bug, probabilmente avrai una buona idea. Funziona per me, in ogni caso.

Fondamentalmente l'azione per scrivere un codice pulito dovrebbe iniziare proprio dalla progettazione. Se stiamo programmando in linguaggio OOP escogitare un UML, condividere con i colleghi e convincerci che il design non è ambiguo. In ogni caso, noi sviluppatori dovremmo convincerci che il design risolve il problema e non gli ambigui.

Quando si tratta di codifica, dobbiamo assicurarci che il progetto venga convertito in codice, ovvero un'entità in una classe o struttura, un'operazione per funzionare ecc.

E ho esaminato un white paper http://queue.acm.org/detail.cfm?id=2063168 che parla di stile di codifica o di come possiamo usare lo spazio, il rientro, la variazione dei caratteri come la maggior parte degli IDE che possiamo usare per scrivere MOLTO Codice CLEANER in cui noi umani possiamo capire tanto quanto le macchine. Sottolinea maggiormente la scrittura di codice libero da commenti in modo che il nostro codice appaia come paragrafi stessi.