Abbiamo una base di codice Java che è diventata troppo grande per un singolo JAR monolitico (più di 5000 classi). Uno dei compiti che stiamo studiando è quanto impegno sarebbe di rompere questo singolo JAR in componenti più piccoli con dipendenze controllate tra di loro. Tuttavia, è un po 'difficile guardare una grande quantità di codice ed essere sicuri di trovare i migliori punti di separazione senza alcuna analisi.Esiste uno strumento di visualizzazione in grado di ispezionare una base di codice Java e segnalare dipendenze tra pacchetti?
Esistono buoni strumenti per ispezionare e visualizzare le dipendenze dell'interpackage? Detto questo, avremmo una serie di punti di taglio suggeriti in cui potremmo iniziare a separare il codice.
Ad esempio, nei giorni precedenti a Netbeans ed Eclipse (e ad un altro lavoro), abbiamo utilizzato TogetherJ e TogetherEnterprise. Quelli avevano la capacità di fare un'analisi del pacchetto statico e disegnare il diagramma UML. Questo tipo di comportamento sarebbe ottimale ma questa caratteristica da sola non è sufficiente per giustificare il costo.
Penso che se hai bisogno di uno strumento per dirti come organizzare le tue 5000 lezioni, allora sei in più problemi di quanto questo strumento possa tirarti fuori. In bocca al lupo. – z5h
@ z5h, onestamente? Perché non dovresti usare uno strumento per cercare le dipendenze? L'output di tale strumento è molto utile per guidare il lavoro di refactoring. Ricorda, questo è il tipo di cosa che ti aiuta a identificare i nodi con un debole accoppiamento reciproco. Questi nodi possono quindi diventare candidati per prodotti di costruzione consegnabili separati. Tempi di costruzione più brevi per entrambi, cambiamenti localizzati, ecc., Sono tutte motivazioni forti per questo tipo di refactoring. Se ci sono strumenti che aiutano a sottolineare "inizia da qui, questo taglio sarebbe facile", perché non dovresti usare una cosa del genere? –
Stavo solo "commentando" che se sei nella fase in cui hai 5000 classi e non c'è abbastanza architettura per guidarti nella giusta direzione senza uno strumento, allora sembra una brutta situazione. Questo non è un esercizio di ottimizzazione in cui uno strumento ti dice cosa guardare dopo. Questa è * l'intera architettura della tua applicazione *, su cui dovresti gestire meglio. Se stai usando lo strumento come verifica delle idee, allora suona bene. Se sta guidando il tuo design, sembra spaventoso. Lo hai reso come se lo strumento guidasse il tuo progetto. – z5h