Comprensione e modifica di grandi progetti

Question

Sono un programmatore principiante e, come parte del mio progetto, devo modificare uno strumento open source (scritto in java) che ha centinaia di classi. Devo modificare una parte significativa di esso per soddisfare le esigenze del progetto. L'ho combattuto per un mese cercando di leggere il codice, cercando di scoprire le funzionalità di ogni classe e cercando di capire la pipeline dall'inizio alla fine.

80% delle classi ha una documentazione incompleta/mancante. Il restante 20% sono quelli che costituiscono l'API generica per lo strumento. Un mese di lettura del codice mi ha appena aiutato a capire l'architettura di base. Ma non sono stato in grado di capire i cambiamenti esatti che devo apportare al mio progetto. Una volta, ho iniziato a modificare una parte del codice e presto ho apportato tante modifiche che non potevo più ricordare.

Un amico mi ha suggerito di provare a scrivere la gerarchia delle classi. C'è un modo migliore (standard?) Per fare questo?

Answer 1

• check-nel codice in qualche repository di codice sorgente (Subversion, CVS, Git, Mercurial ...)
• assicurarsi che si può costruire il progetto dalla sorgente ed eseguirlo
• se già avere un'applicazione che utilizza questo strumento open source provare a rimuovere la dipendenza binaria e introdurre la dipendenza del progetto in eclissi o qualsiasi altro IDE. eseguire il codice e il passaggio attraverso il codice che si vuole capire
• dopo ogni piccolo cambiamento commettere
• se avete idee diverse si diramano il codice

Answer 2

L'unico modo per capire il codice è leggerlo. Continua a lavorare questo è il mio consiglio.

Ci sono progetti con una documentazione migliore di altri. Ecco un paio di progetti che conosco sono ben organizzati: Tomcat, Jetty, Hudson,

Si dovrebbe controllare java-source per progetti più open source.

Answer 3

mio amico, ci si trova in profonda doodoo. La modifica di un codice legacy di grandi dimensioni e mal documentato è uno di quei progetti che fanno sì che i programmatori esperti considerino seriamente le gioie della vendita di assicurazioni o di qualche altra carriera alternativa. Tuttavia non è impossibile, e qui ci sono alcuni consigli che spero possano aiutarti.

Il tuo primo compito è capire il codice il più possibile. Sei almeno sulla strada giusta lì. Ottenere una buona idea della struttura della classe è assolutamente importante, e un diagramma è probabilmente il modo migliore. L'altra cosa che suggerirei è che quando scopri cosa fa una classe, aggiungi tu stesso la documentazione mancante. In questo modo, quando torni indietro, non dimenticherai ciò che hai scoperto.

Non dimenticare il debugger. Se vuoi scoprire cosa sta realmente accadendo, passare attraverso il codice pertinente, o semplicemente scoprire come appare uno stack di chiamate a un certo punto può essere molto utile.

Answer 4

Personalmente penso che sia molto difficile provare a capire un'intera applicazione tutto in una volta. Invece, cerca di concentrarti solo su alcuni moduli. Ad esempio, se è possibile identificare un modulo che è necessario modificare (ad esempio in base a uno schermo o un determinato punto di input/output), iniziare facendo una piccola modifica e verificandola. Vai da lì, facendo un piccolo cambiamento, testando e andando avanti.

Inoltre, se il progetto prevede test di unità (considerarsi fortunato) e rivedere i test di unità del modulo su cui ci si sta concentrando. Questo ti aiuterà a farti un'idea di cosa dovrebbe fare il modulo.

Answer 5

Due cose che Eclipse (e altri IDE) offrono per "combattere" questo. Li ho usati in progetti di grandi dimensioni:

• gerarchia di richiamo - tasto destro del mouse un metodo e scegliere "gerarchia di richiamo", oppure utilizzare CTRL + ALT + H. Questo ti dà tutti i metodi che chiamano il metodo selezionato , con l'opzione di controllare più in basso l'albero. Questa funzione è davvero molto utile.

• Gerarchia di tipi: vedere la gerarchia di ereditarietà delle classi. In Eclipse E 'F4 o CTRL + T.

anche:

• trovare un modo per fare in modo che le modifiche abbiano effetto on-salvataggio, e non c'è bisogno di ridistribuire
• uso un debugger - eseguito in modalità debug, all'interno dell'IDE, in modo da vedere come procede il flusso

Answer 6

A mio parere non esiste un approccio standard per comprendere un progetto. Dipende da molti fattori, dalla comprensibilità del codice/architettura che stai analizzando alla tua esperienza precedente su progetti di grandi dimensioni.

Ti suggerisco di decodificare il codice utilizzando uno strumento di modellazione, in modo da poter generare alcuni modelli UML dal codice sorgente esistente. Questi diagrammi possono essere utili come linee guida grafiche durante le anays del codice.

Non abbiate paura di utilizzare il debug per afferrare la logica delle funzionalità più complesse del progetto. L'esecuzione dell'istruzione di codice più complessa mediante istruzioni, può essere utile per visualizzare i valori esatti delle variabili e le interazioni tra gli oggetti.

Prima di refactoring per modificare il progetto in base alle proprie esigenze, assicurarsi di scrivere alcuni casi di test, in modo che è possibile verificare che le modifiche non infrangono il codice in modi imprevisti.

Answer 7

Qui ci sono un paio di raccomandazioni

• Crea il codice in qualche forma di CVS. In questo modo se si apportano modifiche è sempre possibile guardare indietro alle versioni precedenti di .
• Prenditi il ​​tempo per documentare ciò che hai già acquisito/completato. . Javadoc va bene per questo .
• Creare una struttura UML per il codice. Ci sono molti plugin là fuori e ti forniremo una buona rappresentazione del layout del codice.

Answer 8

C'è un grande libro chiamato Working Effectively with Legacy Code, di Michael Feathers. C'è una versione più breve dell'articolo here.

Uno dei suoi punti è che la cosa migliore che puoi fare è scrivere test unitari per il codice esistente.Questo ti aiuta a capire dove sono i punti di ingresso e come dovrebbe funzionare il codice. Quindi ti consente di refactoring senza preoccuparti di romperlo.

Dall'articolo collegato, la sintesi della sua strategia:

1. Identify change points 
2. Find an inflection point 
3. Cover the inflection point 
    a. Break external dependencies 
    b. Break internal dependencies 
    c. Write tests 
4. Make changes 
5. Refactor the covered code.