Come trovare codice non utilizzato / morto nei progetti Java
https://stackoverflow.com/questions/162551
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
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 anche apprezzati suggerimenti per strategie / tecniche generali (diversi dagli strumenti specifici).
Modifica: Nota che utilizziamo già 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 cluster di codice che hanno pochissimo altro codice a seconda di esso, consentendo l'ispezione manuale dei documenti.
Soluzione
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 sei interessato 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 non utilizzate.
Naturalmente, 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ù penalità di prestazione. Forse una cosa simile può essere fatta in Java con flag booleani statici ...
Altri suggerimenti
Un plug-in Eclipse che funziona abbastanza bene è Rilevatore di codice inutilizzato .
Elabora un intero progetto o un file specifico e mostra vari metodi di codice inutilizzati / non funzionanti, 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 plug-in ha una funzione " Trova codice morto 'con uno / più punti di ingresso (S). Funziona abbastanza bene.
Sono sorpreso ProGuard non è stato menzionato qui. È uno dei prodotti più maturi in circolazione.
ProGuard è un restringitore, ottimizzatore, offuscatore di file di classe Java gratuito, e preverificatore. Rileva e rimuove classi, campi inutilizzati, metodi e attributi. Ottimizza il bytecode e rimuove inutilizzati Istruzioni. Rinomina le restanti classi, campi e metodi usando nomi insignificanti brevi. Infine, preverifica il elaborato codice 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 memoria più piccola impronte.
- Rendere i programmi e le librerie più difficili da decodificare.
- Elencando il codice morto, in modo che possa essere rimosso dal codice sorgente.
- Retargeting e pre-verifica dei file di classe esistenti per Java 6 o versioni successive, per sfruttare appieno il caricamento di classe più veloce.
Ecco un esempio di codice morto per la lista: 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.
Abbiamo iniziato a utilizzare Trova bug per aiutare a identificare parte del funk nella nostra base di codice ricca di target ambiente per 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 il codice inutilizzato. C'è una prova 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 delle classi in base all'input dell'utente, ai file di configurazione, alle voci del database, ecc .;
- Caricamento codice esterno;
- Passando gli alberi degli oggetti a librerie di terzi;
- ecc.
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 è " t chiamato è taggato inutilizzato ma un metodo pubblico richiede analisi più approfondite.
In Eclipse Vai a Windows > Preferenze > Java > Compilatore > Errori / avvisi
e cambiarli tutti in errori. Risolvi tutti gli errori. Questo è il modo più semplice. Il bello è che questo ti permetterà di ripulire il codice mentre scrivi.
Codice Eclipse della schermata:
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 non utilizzati
Vorrei anche provare a individuare il codice duplicato per ridurre il volume del codice.
Il mio ultimo suggerimento è di cercare un codice open source che, se usato, semplificherebbe il tuo codice.
Structure101 prospettiva fetta fornirà un elenco (e grafico delle dipendenze) di tutti gli "orfani" oppure " orphan gruppi " di classi o pacchetti che non hanno dipendenze da o verso la "principale" grappolo.
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 . Ci proverò.
P.S. Come menzionato in un commento qui sotto, il Progetto ora vive 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 questo 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 vero codice morto. 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 stai correndo in un ambiente ridondante con bilanciamento del carico (e se no, perché no?) allora suppongo che avrebbe senso strumentare solo un'istanza della tua applicazione e configurare il tuo bilanciamento del carico in modo che sia casuale, ma piccolo , parte degli utenti viene eseguita sull'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 usati 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 ecco un plugin per Netbeans rilevatore di codice morto .
Sarebbe meglio se potesse collegarsi ed evidenziare il codice inutilizzato. Puoi votare e commentare qui: Bug 181458 - Trova classi, metodi, campi pubblici non utilizzati
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 per le applicazioni Web (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.
