Comment trouver du code inutilisé/mort dans les projets java
Quels outils utilisez-vous pour trouver du code inutilisé/mort dans les grands projets java? Notre produit est en développement depuis quelques années, et il devient très difficile de détecter manuellement le code qui n'est plus utilisé. Nous essayons cependant de supprimer autant de code inutilisé que possible.
Les Suggestions de stratégies/techniques générales (autres que des outils spécifiques) sont également appréciées.
Edit: notez que nous utilisons déjà des outils de couverture de code (Clover, IntelliJ), mais ceux-ci sont de peu aider. Le code mort a toujours des tests unitaires, et apparaît comme couvert. Je suppose qu'un outil idéal identifierait des clusters de code qui ont très peu d'autres codes en fonction, permettant une inspection manuelle des documents.
21 réponses
J'instrumenterais le système en cours d'exécution pour conserver les journaux d'utilisation du code, puis commencer à inspecter le code qui n'est pas utilisé pendant des mois ou des années.
Par exemple, si vous êtes intéressé par les classes inutilisées, toutes les classes peuvent être instrumentées pour se connecter lorsque des instances sont créées. Et puis un petit script pourrait comparer ces journaux à la liste complète des classes pour trouver des classes inutilisées.
Bien sûr, si vous allez au niveau de la méthode, vous devez garder les performances à l'esprit. Par exemple, les méthodes ne pouvait enregistrer leur première utilisation. Je ne sais pas comment cela est mieux fait en Java. Nous l'avons fait dans Smalltalk, qui est un langage dynamique et permet ainsi de modifier le code à l'exécution. Nous analysons toutes les méthodes avec un appel de journalisation et désinstallons le code de journalisation après la première journalisation d'une méthode, donc après un certain temps, plus de pénalités de performance se produisent. Peut-être qu'une chose similaire peut être faite en Java avec des drapeaux booléens statiques...
Un plugin Eclipse qui fonctionne raisonnablement bien est Détecteur de Code inutilisé .
Il traite un projet entier, ou un fichier spécifique et montre diverses méthodes de code inutilisées/mortes, ainsi que suggérant des changements de visibilité (c'est-à-dire une méthode publique qui pourrait être protégée ou privée).
CodePro a été récemment publié par Google avec le projet Eclipse. Il est gratuit et très efficace. Le plugin a une fonctionnalité 'Find Dead Code ' avec un / plusieurs points d'entrée(s). Fonctionne assez bien.
Je suis surpris ProGuard n'a pas été mentionné ici. C'est l'un des la plupart des produits matures autour de.
ProGuard est un shrinker de fichiers de classe Java gratuit, optimiseur, obfuscator, et prévérificateur. Il détecte et supprime les classes inutilisées, les champs, méthodes et attributs. Il optimise le bytecode et supprime les inutilisés instruction. Il renomme les classes, champs et méthodes restants en utilisant des noms courts sans signification. Enfin, il prévérifie le traité code pour Java 6 ou pour Java Micro Edition.
Certaines utilisations de ProGuard sont:
- création de code plus compact, pour des archives de code plus petites, un transfert plus rapide sur les réseaux, un chargement plus rapide et une mémoire plus petite empreinte.
- rendre les programmes et les bibliothèques plus difficiles à désosser.
- liste de code mort, de sorte qu'il peut être retiré du code source.
- reciblage et prévérification des fichiers de classe existants pour Java 6 ou supérieur, pour avantage de leur chargement de classe plus rapide.
Une chose que j'ai connue pour faire dans Eclipse, sur une seule classe, est de changer toutes ses méthodes en privé, puis de voir quelles plaintes Je reçois. Pour les méthodes utilisées, cela provoquera des erreurs, et je les renvoie au niveau d'accès le plus bas possible. Pour les méthodes inutilisées, cela provoquera des avertissements sur les méthodes inutilisées, et celles-ci peuvent ensuite être supprimées. Et en prime, vous trouvez souvent des méthodes publiques qui peuvent et doivent être rendues privées.
Mais c'est très manuel.
Nous avons commencé à utiliser Find Bugs pour aider à identifier une partie du funk dans l'environnement riche en cibles de notre base de code pour les refactorings. Je considérerais aussi Structure 101 pour identifier les taches dans l'architecture de votre base de code qui sont trop compliquées, donc vous savez où sont les vrais marais.
En théorie, vous ne pouvez pas déterminer de manière déterministe le code inutilisé. Il y a une preuve mathématique de cela (eh bien, c'est un cas particulier d'un théorème plus général). Si vous êtes curieux, recherchez le problème D'arrêt.
Cela peut se manifester dans le code Java de plusieurs façons:
- chargement des classes basées sur l'entrée de l'utilisateur, les fichiers de configuration, les entrées de base de données, etc.;
- chargement du code externe;
- passer des arborescences d'objets à des bibliothèques tierces;
- etc.
Cet être dit, j'utilise IDEA IntelliJ comme IDE de choix et il dispose d'outils d'analyse complets pour les dépendances findign entre les modules, les méthodes inutilisées, les membres inutilisés, les classes inutilisées, etc. C'est assez intelligent aussi comme une méthode privée qui n'est pas appelée est étiquetée inutilisée mais une méthode publique nécessite une analyse plus approfondie.
Dans Eclipse Goto Windows > Préférences > Java > Compilateur > Erreurs/Avertissements
et changez-les tous en erreurs. Corrigez toutes les erreurs. C'est la façon la plus simple. La beauté est que cela vous permettra de nettoyer le code que vous écrivez.
Capture D'Écran Code Eclipse:
IntelliJ a des outils d'analyse de code pour détecter le code qui n'est pas utilisé. Vous devriez essayer de rendre autant de champs / méthodes / classes que possible non publics et cela affichera plus de méthodes/champs/classes inutilisés
J'essaierais également de localiser le code en double comme moyen de réduire le volume de code.
Ma dernière suggestion est d'essayer de trouver du code source ouvert qui, s'il est utilisé, simplifierait votre code.
La Structure101perspective de tranche donnera une liste (et un graphique de dépendance) de tous les "orphelins" ou "orphelinsgroupes " de classes ou de paquets qui n'ont pas de dépendances vers ou depuis le cluster "principal".
DCD n'est pas un plugin pour certains IDE mais peut être exécuté depuis ant ou autonome. Il ressemble à un outil statique et Il peut faire ce que PMD et FindBugs ne peuvent pas . Je vais l'essayer.
PS le projet semble mort maintenant. Il y a un plugin PMD maintenant, mais je ne l'ai pas utilisé.
Il existe des outils qui profilent le code et fournissent des données de couverture de code. Cela vous permet de voir (comme le code est exécuté) combien il est appelé. Vous pouvez obtenir l'un de ces outils pour savoir combien de code orphelin vous avez.
- FindBugs est excellent pour ce genre de chose.
- PMD (Project Mess Detector) est un autre outil qui peut être utilisé.
Cependant, aucun des deux ne peut trouver les méthodes statiques publiques {[8] } inutilisées dans un espace de travail. Si quelqu'un connaît un tel outil, faites-le moi savoir.
Outils de couverture utilisateur, tels que EMMA. Mais ce n'est pas un outil statique (c'est-à-dire qu'il nécessite d'exécuter l'application via des tests de régression, et à travers tous les cas d'erreur possibles, ce qui est, bien, impossible :))
Pourtant, EMMA est très utile.
Les outils de couverture de Code, tels que Emma, Cobertura et Clover, analyseront votre code et enregistreront les parties invoquées en exécutant une suite de tests. Ceci est très utile et devrait faire partie intégrante de votre processus de développement. Cela vous aidera à identifier dans quelle mesure votre suite de tests couvre votre code.
Cependant, ce n'est pas la même chose que d'identifier le vrai code mort. Il identifie uniquement le code qui est couvert (ou non couvert) par des tests. Cela peut vous donner des faux positifs (si votre les tests ne couvrent pas tous les scénarios) ainsi que les faux négatifs (si vos tests code d'accès qui est en fait jamais utilisé dans un scénario du monde réel).
J'imagine que la meilleure façon d'identifier vraiment le code mort serait d'Instrumenter votre code avec un outil de couverture dans un environnement de fonctionnement en direct et d'analyser la couverture de code sur une longue période de temps.
Si vous exécutez dans un environnement redondant équilibré en charge (et sinon, pourquoi pas?) alors je suppose qu'il serait logique de ne utilisez une instance de votre application et configurez votre équilibreur de charge de sorte qu'une partie aléatoire, mais petite, de vos utilisateurs s'exécute sur votre instance instrumentée. Si vous le faites sur une longue période de temps (pour vous assurer que vous avez couvert tous les scénarios d'utilisation du monde réel - telles variations saisonnières), vous devriez être en mesure de voir exactement quelles zones de votre code sont accessibles sous utilisation du monde réel et quelles parties ne sont vraiment jamais accessibles et donc code mort.
Je n'ai jamais personnellement vu Cela fait, et je ne sais pas comment les outils susmentionnés peuvent être utilisés pour instrumenter et analyser le code qui n'est pas invoqué via une suite de tests - mais je suis sûr qu'ils peuvent l'être.
Il existe un projet Java - Détecteur de code Mort (DCD). Pour le code source, cela ne semble pas bien fonctionner, mais pour .fichier jar-il est vraiment bon. De plus, vous pouvez filtrer par classe et par méthode.
Netbeans voici un plugin pour Netbeans code mort détecteur de.
Ce serait mieux si elle pouvait lier et mettre en évidence le code inutilisé. Vous pouvez voter et commenter ici: Bug 181458-trouver des classes publiques inutilisées, des méthodes, des Champs
Eclipse peut afficher / mettre en surbrillance le code qui ne peut pas être atteint. JUnit peut vous montrer la couverture du code, mais vous auriez besoin de quelques tests et devez décider si le test pertinent est manquant ou si le code est vraiment inutilisé.
J'ai trouvé L'outil de couverture de trèfle qui code les instruments et met en évidence le code qui est utilisé et qui est inutilisé. Contrairement à Google CodePro Analytics, cela fonctionne également pour les applications web (selon mon expérience et je peux être incorrect à propos de Google CodePro).
Le seul inconvénient que j'ai remarqué est qu'il ne prend pas en compte les interfaces Java.
J'utilise Doxygen pour développer une carte d'appel de méthode pour localiser les méthodes qui ne sont jamais appelées. Sur le graphique, vous trouverez des îlots de clusters de méthodes sans appelants. Cela ne fonctionne pas pour les bibliothèques car vous devez toujours commencer à partir d'un point d'entrée principal.