In precedenza stavo cercando un buon controllo TimeLine per un progetto WPF. Ho trovato una risposta in qui che mi indirizza a questo progetto CodePlex .
Ora voglio cambiare il codice per soddisfare le mie esigenze culturali. Ma ci sono alcuni disallineamenti!
La mia domanda è:
Come interagisci con migliaia di righe di codice?
EDIT:
Qualsiasi scorciatoia sarà eccezionale!
Aggiungi commenti al codice sorgente quando hai capito abbastanza per essere in grado di farlo. Riforma questi commenti con vigore man mano che comprendi sempre di più.
... e il codice ti ringrazierà per questo. ; -)
Fai una singola azione, fai il debug (ancora e ancora) il codice per scoprire come viene eseguita quell'azione. Scrivi lo stesso in un linguaggio semplice per ottenere una migliore comprensione!
Qualcosa che Joel Spolsky ha scritto nel passato quando sul suo blog (non riesco a trovare l'articolo adesso) mi ha davvero impressionato riguardo a questo:
Ha detto che il codice non è un linguaggio umano naturale, ma come programmatori, siamo facilmente cullati nel pensare che lo sia, e che dovremmo essere in grado di leggerlo come tale. Di conseguenza, molti di noi guardano al 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 solo essere lenti, metodici e scientifici. E come altri hanno già detto - commentalo (e anche il refactoring) mentre vai. Non cadere nella mentalità di "dovrei solo guardarlo e capire immediatamente".
Oh, e sì, a volte mi caccio ancora in questa trappola. "Fai come dico, non come faccio io", e tutto il resto. :)
SE-Radio ha intervistato Dave Thomas 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.
L'ho dovuto fare di recente con un progetto di oltre 100.000 LOC. La mia prima idea è che è più facile vedere i modelli da grafici di 100 o persino 1000 nodi rispetto a 100.000 righe di testo.
Così ho trascorso 45 minuti e ho scritto un programma Python breve (< 100LOC) per analizzare ciò che mi serviva e disegnare le relazioni dell'oggetto. Ho generato Graphviz sorgente, che è una lingua veramente facile da generare. (Non c'è niente di speciale in Python qui: Ruby o C # o Common Lisp o qualsiasi altra cosa potrebbe farlo altrettanto bene.)
Su altri progetti, ho visto persone usare Graphviz per le dipendenze dei moduli, i grafici delle chiamate, la cronologia delle versioni, tutti i tipi di cose. Il più grande strumento di visualizzazione dei programmi di sempre.
(Forse è perché ho ho preso i compilatori , ma lo trovo strano che quando un programmatore si trova ad affrontare un problema, la risposta sembra essere sempre "scrivi un programma!", tranne quando il problema riguarda il codice sorgente di un programma.: -)
Passa attraverso di esso nel debugger mentre è in esecuzione, è quasi l'unico modo per capire una nuova e larga base di codice.
Comprendi che non ci sono davvero scorciatoie per il grokking in pienezza. (E se hai problemi con quella frase, la tua educazione è stata SORAMENTE trascurata. È tratta da "Stranger In a Strange Land", di Robert A. Heinlein.)
Leggilo, una pagina alla volta, una routine alla volta. Aggiungi commenti. Disegna le immagini delle principali strutture di dati. Riconosci gli algoritmi. Attingi alle conoscenze precedenti.
Resisti alla tentazione di avviare il debugger. La finestra di visualizzazione del debugger è troppo piccola: vedi una riga alla volta, ma davvero non vedi dove sei stato o dove stai andando.
Qualunque cosa tu faccia scrivi il più possibile mentre procedi così nessuno finirà mai nella stessa posizione che hai.
devi usare indizi. ottenere un indizio su ciò che si deve cercare e utilizzare ampiamente la funzionalità di ricerca del proprio ambiente o IDE che può portare alla sezione desiderata del codice che è necessario apportare modifiche.
leggere 14 mila righe di codice java non ha alcun senso. La funzionalità di ricerca è il tuo risparmiatore di vita
Diverse persone hanno diversi stili di apprendimento, quindi YMMV. La prima cosa che faccio in questa situazione è leggere l'intero codice base almeno una volta. Questo mi dà un'idea generale di dove sia tutto. Quindi scelgo una sezione per esaminare più in dettaglio. 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 la prima. Dopo un numero sufficiente di iterazioni, ho una buona idea di come funziona il codice.
Il modo migliore, come con tutta la programmazione, non solo pezzi grandi di codice non commentato, è di scomporlo in pezzi. Questo è sia qualcosa che dovresti fare nella tua testa sia visivamente nel codice. Ciò potrebbe significare aggiungere grandi commenti in grassetto o più interruzioni di riga. Questo aiuta mentre lo si scorre per vedere i pezzi. Prova a trovare i pezzi logici del codice.
Ovviamente, mentre comprendi i bit, commentali per quello che sai in quel momento, magari inserendo note su qualcosa che non capisci.
Raccomando anche di non provare a capire l'intero pezzo fin dall'inizio. Cerca invece di capire i pezzi che devi sapere in questo momento e lavora sul resto in seguito.
Vorrei iniziare utilizzando Editor Leo in @ shadow mode con uso attivo di nodi clonati . Ciò consente di aggiungere note e commenti per ogni sezione di codice sotto studio senza modificare il codice e le annotazioni saranno sempre nel contesto, accanto al codice di cui si parla. Ecco un esempio di flusso di lavoro, i documenti:
For example, when I fix a bug in Leo, I create an ordinary node to represent the bug. This bug node is my view of all the data in Leo’s source code that relates to the bug. As I discover code related to the bug, I clone their nodes and move them under the bug node. I’ll also add ordinary nodes as children of the bug node. These nodes contain the original bug report, descriptions of how I fixed the bug, test data, or any other notes I might want to keep.
Once I have created the bug node, I concentrate only on that node and its children. I can examine the bug node and its children without having to jump around the outline. Everything I need is in one place. When I get around to actually fixing the bug I can do so by changing the clones. Again, I do not have to jump around the outline. It doesn’t matter how big or complex the entire outline is: I am only dealing with the bug node and its children. This extremely narrow focus makes it much easier to fix bugs.
Disegna i diagrammi dell'origine: le relazioni dei dati, le relazioni funzionali, le relazioni dell'oggetto. Determinare l'aggregazione, il flusso di dati e il flusso di codice. Le immagini sono di gran lunga migliori dei commenti per questo e possono essere mantenute separate dal codice.
Prima di refactare qualcosa scrivi test. Un sacco di test. Test molto specifici su piccoli blocchi di codice che sono almeno richiamabili, poiché dipenderanno da come viene scritto il tuo pasticcio ereditato.
Il vantaggio di scrivere i test per iniziare è che devi avere un qualche tipo di comprensione del codice prima di poterlo testare, quindi ogni test che scriverai si spera che sia un po 'di conoscenza acquisita. Puoi anche commentare pesantemente i test con le tue ipotesi accanto alle affermazioni.
Prima fai il test, non corri il rischio di alterare qualcosa nel codice che ha effetti a catena di cui non puoi sapere nulla. Avrai anche una rete di sicurezza quando arriverete al refactoring del codice.
Uso strumenti come doxygen, per generare un diagramma generale della classe, che aggiunge la mia comprensione di ciò che fanno ciascuna classe.
Poi raccolgo alcuni bug facili dalla coda dei bug (prima che il mio manager assegni a me uno difficile: P), quindi eseguo questa funzionalità nel debugger e provo a generare un flusso di dati approssimativo o un modello di flusso di codice.
Ad esempio, la funzionalità di esportazione in alcuni software: così provo a capire come vengono letti i dati di origine, da dove nel codice (interfaccia di base) posso valutare i dati vengono letti correttamente usando i miei diagrammi di flusso di codice e classe, quali classi sono responsabile del tipo di esportazione, ecc. Penso che la metà della comprensione sia fatta, una volta che hai i diagrammi delle classi e i diagrammi di flusso.
Avvicinati a un difetto insignificante, ad es. una NullPointerException. Evitare tutto ciò che riguarda la concorrenza in un primo momento, qualsiasi cosa che per sua natura implicherà la comprensione di gran parte del codice contemporaneamente.
Una volta risolti alcuni bug, probabilmente avrai una buona idea. Funziona per me, in ogni caso.
Fondamentalmente l'azione per scrivere un codice pulito dovrebbe iniziare direttamente dal design. Se stiamo codificando in linguaggio OOP, creiamo un UML, condividiamo con i colleghi e ci convinciamo che il design non è ambiguo. In ogni caso noi sviluppatori dovremmo convincerci che il design risolve il problema e non ambiguos.
Per quanto riguarda la codifica, dobbiamo assicurarci che il progetto venga convertito in codice, cioè un'entità in una classe o in una struttura, un'operazione da eseguire ecc.
E ho seguito un white paper link che parla dello stile di codifica o di come possiamo usare lo spazio , indentazione, variazione dei font come la maggior parte degli IDE possiamo usare per scrivere il codice MUCH CLEANER dove noi umani possiamo capire quanto le macchine. Sottolinea più sulla scrittura di codice gratuito per i commenti in modo che il nostro codice appaia come se stesso.
Leggi altre domande sui tag project-management source-code