Come trovare codice non utilizzato / morto nei progetti Java [chiuso]

Quali strumenti usi per trovare codice non utilizzato / morto in grandi progetti Java? Il nostro prodotto è in fase di sviluppo da alcuni anni e sta diventando molto difficile rilevare manualmente il codice che non è più in uso. Cerchiamo comunque di eliminare quanto più codice inutilizzato possibile.

Sono apprezzati anche suggerimenti per strategie / tecniche generali (diversi dagli strumenti specifici).

Modifica: Nota che già utilizziamo strumenti di copertura del codice (Clover, IntelliJ), ma questi sono di scarso aiuto. Il codice morto ha ancora test unitari e si presenta come coperto. Immagino che uno strumento ideale identificherebbe i gruppi di codice che hanno pochissimo altro codice a seconda di esso, consentendo l'ispezione manuale dei documenti.

Strumenterei il sistema in esecuzione per tenere registri dell'utilizzo del codice e quindi iniziare a ispezionare il codice che non viene utilizzato per mesi o anni.

Ad esempio, se si è interessati a classi inutilizzate, tutte le classi potrebbero essere strumentate per registrare quando vengono create le istanze. Quindi un piccolo script potrebbe confrontare questi registri con l'elenco completo delle classi per trovare le classi inutilizzate.

Ovviamente, se vai a livello di metodo, dovresti tenere a mente le prestazioni. Ad esempio, i metodi potevano registrare solo il loro primo utilizzo. Non so come sia meglio farlo in Java. Lo abbiamo fatto in Smalltalk, che è un linguaggio dinamico e consente quindi la modifica del codice in fase di esecuzione. Strumentiamo tutti i metodi con una chiamata di registrazione e disinstalliamo il codice di registrazione dopo che un metodo è stato registrato per la prima volta, quindi dopo un po 'di tempo non si verificano più penali di prestazione. Forse una cosa simile può essere fatta in Java con flag booleani statici ...

Un plugin Eclipse che funziona abbastanza bene è Unused Code Detector .

Elabora un intero progetto o un file specifico e mostra vari metodi di codice inutilizzato / morto, oltre a suggerire cambiamenti di visibilità (ovvero un metodo pubblico che potrebbe essere protetto o privato).

CodePro è stato recentemente rilasciato da Google con il progetto Eclipse. È gratuito e molto efficace. Il plugin ha una funzione ' Trova codice morto ' con uno / più punti di ingresso. Funziona abbastanza bene.

Sono sorpreso che ProGuard non sia stato menzionato qui. È uno dei prodotti più maturi in circolazione.

ProGuard è un restringitore, ottimizzatore, offuscatore e preverificatore di file Java gratuito. Rileva e rimuove classi, campi, metodi e attributi non utilizzati. Ottimizza il bytecode e rimuove le istruzioni non utilizzate. Rinomina le restanti classi, campi e metodi usando nomi brevi privi di significato. Infine, preverifica il codice elaborato per Java 6 o Java Micro Edition.

Alcuni usi di ProGuard sono:

• Creazione di codice più compatto, per archivi di codice più piccoli, trasferimento più veloce attraverso le reti, caricamento più veloce e impronte di memoria più piccole.
• Rendere i programmi e le librerie più difficili da decodificare.
• Elenco del codice morto, quindi può essere rimosso dal codice sorgente.
• Retargeting e pre-verifica dei file di classe esistenti per Java 6 o versioni successive, per sfruttare appieno il loro caricamento di classe più veloce.

Ecco un esempio di elenco dei codici non validi : https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

Una cosa che sono stato conosciuto per fare in Eclipse, su una singola classe, è cambiare tutti i suoi metodi in privato e poi vedere quali lamentele ricevo. Per i metodi utilizzati, ciò provocherà errori e li restituirò al livello di accesso più basso possibile. Per i metodi non utilizzati, ciò provocherà avvisi sui metodi non utilizzati e questi potranno quindi essere eliminati. E come bonus, spesso trovi alcuni metodi pubblici che possono e devono essere resi privati.

Ma è molto manuale.

Utilizzare uno strumento di copertura test per strumentare la base di codice, quindi eseguire l'applicazione stessa, non i test.

Emma ed Eclemma ti daranno dei bei rapporti su quale percentuale di quali classi vengono eseguite per ogni data esecuzione del codice.

Abbiamo iniziato a utilizzare Trova bug per aiutare a identificare parte del funk nell'ambiente ricco di target della nostra base di codice per i refactoring. Vorrei anche considerare Structure 101 per identificare i punti nell'architettura della tua base di codice che sono troppo complicati, quindi sai dove sono le vere paludi.

In teoria, non è possibile trovare in modo deterministico codice inutilizzato. C'è una dimostrazione matematica di questo (beh, questo è un caso speciale di un teorema più generale). Se sei curioso, cerca il problema Halting.

Questo può manifestarsi nel codice Java in molti modi:

• Caricamento di classi in base all'input dell'utente, ai file di configurazione, alle voci del database, ecc .;
• Caricamento codice esterno;
• Passare alberi degli oggetti a librerie di terzi;
• eccetera.

Detto questo, uso IDEA IntelliJ come IDE di mia scelta e ha ampi strumenti di analisi per trovare dipendenze tra moduli, metodi inutilizzati, membri inutilizzati, classi inutilizzate, ecc. È abbastanza intelligente come un metodo privato che non viene chiamato è taggato inutilizzato ma un metodo pubblico richiede analisi più approfondite.

In Eclipse, vai a Windows> Preferenze> Java> Compilatore> Errori / Avvisi
e modifica tutti in errori. Risolvi tutti gli errori. Questo è il modo più semplice. Il bello è che questo ti permetterà di ripulire il codice mentre scrivi.

Screenshot Codice Eclipse:

IntelliJ dispone di strumenti di analisi del codice per rilevare il codice non utilizzato. Dovresti provare a rendere il maggior numero possibile di campi / metodi / classi non pubblici e ciò mostrerà più metodi / campi / classi inutilizzati

Vorrei anche provare a individuare il codice duplicato come un modo per ridurre il volume del codice.

Il mio ultimo suggerimento è provare a trovare il codice open source che, se usato, renderebbe il tuo codice più semplice.

La prospettiva della sezione Structure101 fornirà un elenco (e un grafico delle dipendenze) di tutti gli "orfani" o " gruppi orfani " di classi o pacchetti che non hanno dipendenze da o verso il cluster "principale".

DCD non è un plug-in per alcuni IDE ma può essere eseguito da formica o autonomo. Sembra uno strumento statico e può fare ciò che PMD e FindBugs non possono fare . Lo proverò.

PS Come menzionato in un commento qui sotto, il Progetto vive ora in GitHub .

Esistono strumenti che codificano il codice e forniscono dati sulla copertura del codice. Questo ti permette di vedere (mentre il codice viene eseguito) quanto viene chiamato. Puoi ottenere uno di questi strumenti per scoprire quanto codice orfano hai.

• FindBugs è eccellente per questo genere di cose.
• PMD (Project Mess Detector) è un altro strumento che può essere utilizzato.

Tuttavia, nessuno dei due può trovare metodi statici pubblici non utilizzati in un'area di lavoro. Se qualcuno conosce un tale strumento, per favore fatemelo sapere.

Strumenti di copertura degli utenti, come EMMA. Ma non è uno strumento statico (cioè richiede di eseguire effettivamente l'applicazione attraverso il test di regressione e tutti i possibili casi di errore, il che è, beh, impossibile :))

Tuttavia, EMMA è molto utile.

Gli strumenti di copertura del codice, come Emma, ​​Cobertura e Clover, strumenteranno il tuo codice e registreranno quali parti vengono invocate eseguendo una serie di test. Questo è molto utile e dovrebbe essere parte integrante del tuo processo di sviluppo. Ti aiuterà a identificare quanto bene la tua suite di test copre il tuo codice.

Tuttavia, questo non è lo stesso dell'identificazione del codice morto reale. Identifica solo il codice che è coperto (o non coperto) dai test. Questo può darti falsi positivi (se i tuoi test non coprono tutti gli scenari) così come falsi negativi (se i tuoi test accedono a un codice che in realtà non viene mai utilizzato in uno scenario del mondo reale).

Immagino che il modo migliore per identificare realmente il codice morto sarebbe quello di strumentare il tuo codice con uno strumento di copertura in un ambiente in esecuzione dal vivo e di analizzare la copertura del codice per un lungo periodo di tempo.

Se si esegue in un ambiente ridondante con bilanciamento del carico (e, in caso contrario, perché no?) Quindi suppongo che avrebbe senso strumentare solo un'istanza dell'applicazione e configurare il bilanciamento del carico in modo tale che una porzione casuale, ma piccola, di i tuoi utenti corrono sulla tua istanza strumentata. Se lo fai per un lungo periodo di tempo (per assicurarti di aver coperto tutti gli scenari di utilizzo del mondo reale - tali variazioni stagionali), dovresti essere in grado di vedere esattamente quali aree del tuo codice sono accessibili sotto l'uso del mondo reale e quali parti davvero non si accede mai e quindi codice morto.

Non l'ho mai visto personalmente e non so come gli strumenti di cui sopra possano essere utilizzati per strumentare e analizzare il codice che non viene invocato attraverso una suite di test, ma sono sicuro che possano esserlo.

Esiste un progetto Java - Dead Code Detector (DCD). Per il codice sorgente non sembra funzionare bene, ma per il file .jar - è davvero buono. Inoltre puoi filtrare per classe e per metodo.

Netbeans qui è un plugin per il rilevatore di codice morto Netbeans .

Sarebbe meglio se potesse collegarsi ed evidenziare il codice inutilizzato. Puoi votare e commentare qui: Bug 181458 - Trova classi, metodi, campi pubblici inutilizzati

Eclipse può mostrare / evidenziare il codice che non può essere raggiunto. JUnit può mostrarti la copertura del codice, ma avresti bisogno di alcuni test e devi decidere se manca il test rilevante o se il codice è davvero inutilizzato.

Ho trovato lo strumento di copertura Clover che codifica strumenti ed evidenzia il codice che viene utilizzato e che non viene utilizzato. A differenza di Google CodePro Analytics, funziona anche con WebApplications (secondo la mia esperienza e potrei non essere corretto su Google CodePro).

L'unico inconveniente che ho notato è che non tiene conto delle interfacce Java.

Uso Doxygen per sviluppare una mappa delle chiamate dei metodi per individuare metodi che non vengono mai chiamati. Nel grafico troverai isole di cluster di metodi senza chiamanti. Questo non funziona per le librerie poiché è necessario iniziare sempre da un punto di ingresso principale.