Sto lavorando a questo progetto, che presto conterrà un sacco di pacchetti, progetti ecc. (Java). Quindi, dall'inizio devo tenere traccia del pacchetto di alto livello e della struttura della classe, monitorare quale classe viene chiamata dove, in modo da non complicarla troppo dopo 6 mesi.
Qual è il modo giusto per farlo? Qualche strumento per questo?
Le due cose più importanti, in primo piano, sono chiare convenzioni di denominazione e documentazione esterna.
Chiare convenzioni di denominazione: le persone dovrebbero essere in grado di capire, entro un ragionevole margine di errore, che cos'è una classe, un pacchetto o un metodo semplicemente leggendo il suo nome. Ciò non significa che hai bisogno di nomi come methodToLoadTheXMLFileAndParseOutPhoneNumbersAndPutThemInAnArrayAndReturnIt (), ma nomi come parseNumbersFromXML () sono migliori di parseNums (). Lo stesso vale per classi, pacchetti e progetti. Entro i limiti del livello di astrazione , i nomi dovrebbero essere auto-descrittivi.
Documentazione esterna: il codice commentato è buono. Il codice sensibile è eccellente. Ma anche il codice estremamente ben commentato è utile solo per capire l'immagine più grande e, quando questo è l'obiettivo, la documentazione esterna è la strada da percorrere. Potrebbero essere documenti di word processor, campi in strumenti di gestione del progetto o qualsiasi altro formato, ma la chiave è avere descrizioni di testo semplici e dirette dei componenti a più livelli di astrazione.
Sono sicuro che c'è altro che gli altri possono aggiungere, ma questo dovrebbe aiutare.
Puoi utilizzare Diagrammi delle classi UML per avere una rappresentazione visiva delle relazioni tra classi e pacchetti.
Ci sono molti strumenti per costruire questi diagrammi. ArgoUML è uno strumento open source che ti permette di costruire questo e altri diagrammi UML, ha anche uno strumento di reverse engineering per generare un diagramma da il tuo codice sorgente.
Ad esempio se generi Javadoc per il tuo codice sorgente, collegamenti ipertestuali tra la documentazione per diverse classi / pacchetti verrà generato automaticamente.
Scrivi test unitari per tutto. Questo ti incoraggerà ad avere un design in cui ogni modulo è autonomo e ha comportamenti ben definiti. Se ti ritrovi a pensare "come diavolo dovrei provare questo?", Di solito è un segno di cattivo design. (Questa non è una regola universale. Alcune cose sono intrinsecamente difficili da scrivere per i test, e non c'è molto che puoi fare a riguardo.)
Inizia con un design !!!
Gli strumenti CASE come Enterprise Architect (è quello che usiamo al lavoro ed è OK) ecc. ti permettono di progettare le tue classi in UML, progettare i tuoi casi d'uso, le interazioni di classe come diagrammi di sequenza. In questo modo puoi vedere i passi che il programma dovrebbe intraprendere per raggiungere ogni caso d'uso.
L'utilizzo di uno strumento CASE come questo ti consente anche di generare automaticamente il codice dal progetto e quindi di invertire il codice risultante + cambia nuovamente nel design.
In breve, la progettazione e la documentazione di un progetto dovrebbero venire prima di tutto. E se hai fatto un buon design il tuo codice dovrebbe essere facile da seguire.
C'è un trucco per "facile da capire e intuitivo".
Si chiama il principio KISS.
Keep It Simple and Stupid.
"Non riesco a renderlo complicato dopo 6 mesi". è una cosa molto importante da dire.
Potresti renderlo complicato. O potresti mantenerlo semplice.
Puoi mantenerlo semplice, mantenendolo semplice.
Prima di aggiungere ciascuna funzionalità ("carichi di pacchetti, progetti ecc. (Java)"), chiediti se la stai rendendo più semplice o più complessa.
Se lo rendi più complesso, allora FERMA. Smetti di aggiungere cose.
Definisci la complessità che stai vedendo. Risolvi la complessità. Proprio ora prima di aggiungere un'altra riga di codice.
Una volta definita la complessità indesiderabile e riparata, le cose sono di nuovo semplici.
Questa è una battaglia in corso. Nessuna pianificazione impedirà eventualmente la complessità di insinuarsi.
Ogni singola funzione deve superare "questa è l'aggiunta della complessità?" prova.
Suggerisco di mantenere un buon livello di desgin dei domini e dei pacchetti e la loro connessione reciproca.
Per quanto riguarda la documentazione e gli strumenti specifici della classe, non penso che siano necessariamente requisiti importanti, specialmente se lo si fa in un piccolo team o da soli. L'aspetto più importante è scrivere un codice pulito, astratto. Se passi metà del tuo tempo a preoccuparti della documentazione esterna, passerai metà del tempo a non pensare al codice.
Nel dire questo, ritengo che rivalutare concetti di design di alto livello possa aiutarti a mantenere un livello elevato nella scrittura del codice. Ad alto livello intendo solo non scrivere giù ogni classe, o ogni metodo. Considererei invece il modo in cui i gruppi di classi o componenti interagiscono, quale livello concettuale hai e le interfacce tra questi livelli / componenti.
Quindi, in sintesi per tenere traccia del codice e aiutare a mantenere l'astrazione, vorrei seguire questi passaggi:
1) Revisione e progettazione continua di concetti di alto livello utilizzando un approccio UML o anche solo scatole e linee.
2) Utilizzo di TDD su ciascun pacchetto per aiutare ciascun pacchetto a mantenere il codice di accoppiamento libero estensibile.
3) Qualche documentazione del codice su cui è necessario, ma non per essere eccessivamente fissata su questo, poiché è più importante cercare di ottenere il tuo codice da solo.
4) Refactoring costante del tuo codice se noti "durante la scrittura" che esiste una dipendenza elevata da altre modalità. Cerca di non lasciare il codice in uno stato TODO se puoi aiutarlo solo perché sei sotto pressione per farlo. Questo può spesso portare all'inizio del codice disordinato.
Leggi altre domande sui tag code-quality project-management agile java code-smell