Lavoro su progetti Java enterprise che non hanno un singolo punto di accesso da cui posso tracciare il flusso di esecuzione. Alcuni progetti hanno centinaia di classi e, quando mi viene chiesto di aggiungere una funzione a un progetto, mi trovo spesso in difficoltà su dove iniziare a guardare il codice.
Qual è il modo migliore per approfondire tali progetti in modo da poter implementare rapidamente la funzione senza perdere tempo.
Il progetto ha una serie di test unitari ben tenuti? I test unitari sono documentazione programmatica per ciò che fa il codice.
Inoltre, è necessario conoscere abbastanza l'architettura dell'applicazione per identificare i luoghi in cui è necessario inserire il codice per le nuove funzionalità e ignorare più o meno il resto. Non è necessario conoscere l'intera base di codice per farlo; se i progetti sono ben architettati, la funzionalità è già sufficientemente incapsulata e disaccoppiata che è possibile concentrarsi sulle parti rilevanti. Se sei fortunato, i progetti seguono già un'architettura ben nota che servirà da mappa da seguire.
Il codice ha sempre uno o più punti di ingresso. Per i progetti MVC, il punto di ingresso è un metodo di controllo basato su un URL; il metodo accederà quasi certamente a un repository di dati e restituirà una vista. Inizia lì.
Inizia con il livello intermedio (livello della logica aziendale).
Questo è uno dei luoghi in cui viene eseguito il controllo per qualsiasi azione utente o evento trigger se si tratta di un'applicazione non basata sull'interfaccia utente. Se sei in modalità di debug, puoi tracciarlo in alto e in basso (molto probabilmente il livello di accesso ai dati).
Ci vorrà un po 'di tempo, ma questo è il modo efficace per saltare in progetti non documentati.
Se il progetto utilizza qualsiasi framework (struts-config.xml, ejb config xmls, spring config xmls) avrà un'interfaccia definita e puoi anche partire da lì.
C'è sempre un punto di ingresso. Per le app enterprise Java: servlet, filtri e listener di contesto sono in cima, normalmente portano al bootstrap dell'applicazione, ad esempio il caricatore di contesto spring, che quindi conduce ai controller, quindi in entità e viste. In realtà è piuttosto semplice, soprattutto se si utilizza una struttura come la primavera, l'arazzo o il wicket. Una volta che sai come il framework elabora una richiesta, dovresti essere in grado di identificare i punti di estensione di cui hai bisogno.
Vorrei iniziare con una gerarchia di classi. Se ne possiedi uno fantastico, in caso contrario, trova uno strumento in grado di decodificare il codice e crearne uno per te. Da ciò puoi iniziare a vedere come possono essere correlate le cose. Una volta che puoi vedere come le cose possono essere correlate puoi almeno colpire le aree invece di avere un grande "guazzabuglio" di classi. Puoi scegliere come target un'area in cui puoi vedere come sono associati tra loro (questa classe è un'associazione di questa, è questa serie di classi un modello di progettazione, ecc.). Cerca di aggiungere un ordine e una struttura intorno a ciò che stai guardando e quindi suddividere ogni sezione.
EDIT:
Ecco alcuni post dello stack overflow che descrivono gli strumenti che puoi usare in eclissi (o come applicazioni standalone) per decodificare e generare un modello:
"Come mangi un elefante". "Un morso alla volta".
Questo è quasi impossibile estendere il tuo progetto java se non ottieni i punti di ingresso e una documentazione chiara di ciò che è stato fatto e perché.
FYI: Quando consegniamo un progetto ai nostri clienti, ora aderiamo sistematicamente a un modello UML, a un documento java ea una documentazione stampata. Creiamo centinaia di viste dal modello visualizzato come diagrammi di classe. Aggiungiamo numerosi commenti e spieghiamo l'architettura statica e il flusso di regole e metodi aziendali. Se i nostri clienti vogliono prendere il suo codice e consegnarlo a un'altra società, sarà facile per loro modificare il software esistente non solo a livello di implementazione ma anche a livello di architettura. Uso potente, semplice e brillante di viste dinamiche UML da un singolo modello.
Detto questo, conosco pochissimi integratori interessati a fornire tutte queste informazioni perché una volta che il cliente è intrappolato è meglio non lasciarlo andare. Offrire un modello completo e una navigazione dinamica in UML consentiranno ai clienti di essere indipendenti e quindi questo non va bene per le entrate aziendali. Continuo a non capire perché le grandi banche o le compagnie di telecomunicazioni sono così ingenue da essere intrappolate dagli integratori e non chiedono il modello completo alla consegna del progetto? Il codice java o una documentazione stampata non sono sufficienti. La documentazione stampata di solito è un processo automatico. Non ha alcun valore reale per estrarre informazioni dal codice per stamparlo o fornire un PDF.
Ci sono dei punti di accesso SEMPRE, devi solo trovarli. Se si tratta di un'applicazione batch basata su pianificazione, ci sono attività configurate da qualche parte. Se si tratta di un'applicazione Web (utilizzando Spring), esistono mapping e controller. Se si tratta di un'applicazione di servizi Web, esistono endpoint di servizio. Se si tratta di un'applicazione Swing, ci sono gestori di eventi o somesuch. E se si tratta di una grossa applicazione da riga di comando, esiste un metodo main() .
Per quanto riguarda "l'immersione in fretta" - beh, quanto tempo ci vuole per trovare i punti di ingresso è davvero individuale. Se il sistema è scritto secondo schemi prestabiliti e hai familiarità con i framework e le regole e i processi aziendali sottostanti, allora dovresti essere in grado di capirli molto velocemente. In caso contrario, potrebbe richiedere più tempo. Ma non esiste un "trucco" universale. Accumuli esperienza, impari a riconoscere i modelli e comprendi come i quadri sono costruiti e organizzati e tu stai migliorando.
Per quanto riguarda la gestione del codice precedente:
Riguardo al flusso di esecuzione:
Per quanto riguarda il punto di ingresso:
Leggi altre domande sui tag design entry-point