Comment trouver le code inutilisé / mort dans les projets java [fermé]

Quels outils utilisez-vous pour trouver le 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.

Des 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 peu utiles. Le code mort a toujours des tests unitaires et apparaît comme couvert. Je suppose qu'un outil idéal identifierait des grappes de code qui ont très peu de code en fonction, permettant une inspection manuelle des documents.

J'instrumenterais le système en cours d'exécution pour conserver des journaux d'utilisation du code, puis commencerais à 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 avec la liste complète des classes pour trouver les classes inutilisées.

Bien sûr, si vous allez au niveau de la méthode, vous devez garder à l'esprit les performances. Par exemple, les méthodes n'ont pu enregistrer que leur première utilisation. Je ne sais pas comment cela se fait au mieux en Java. Nous l'avons fait dans Smalltalk, qui est un langage dynamique et permet donc de modifier le code lors de l'exécution. Nous instrumentons toutes les méthodes avec un appel de journalisation et désinstallons le code de journalisation une fois qu'une méthode a été journalisée pour la première fois, donc après un certain temps, il n'y a plus de pénalités de performances. 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 Unused Code Detector .

Il traite un projet entier ou un fichier spécifique et montre diverses méthodes de code inutilisé / mort, ainsi que des suggestions de changements de visibilité (c'est-à-dire une méthode publique qui pourrait être protégée ou privée).

CodePro a récemment été 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 point (s) d'entrée. Fonctionne plutôt bien.

Je suis surpris que ProGuard n'ait pas été mentionné ici. C'est l'un des produits les plus matures du marché.

ProGuard est un rétrécisseur, optimiseur, obfuscateur et prévérificateur de fichiers de classe Java gratuits. Il détecte et supprime les classes, champs, méthodes et attributs inutilisés. Il optimise le bytecode et supprime les instructions inutilisées. Il renomme les classes, champs et méthodes restants en utilisant des noms courts sans signification. Enfin, il prévérifie le code traité pour Java 6 ou 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 des empreintes de mémoire plus petites.
• Rendre les programmes et les bibliothèques plus difficiles à rétroconcevoir.
• Liste du code mort, afin qu'il puisse être supprimé du code source.
• Retargeting et pré-vérification des fichiers de classe existants pour Java 6 ou supérieur, pour profiter pleinement de leur chargement de classe plus rapide.

Voici un exemple de code mort de liste: https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

Une chose que l'on sait faire dans Eclipse, sur une seule classe, est de changer toutes ses méthodes en privé et de voir ensuite les plaintes que j'obtiens. Pour les méthodes utilisées, cela provoquera des erreurs et je les ramènerai 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 trouverez souvent des méthodes publiques qui peuvent et doivent être rendues privées.

Mais c'est très manuel.

Utilisez un outil de couverture de test pour instrumenter votre base de code, puis exécutez l'application elle-même, pas les tests.

Emma et Eclemma vous donneront de bons rapports sur le pourcentage de quelles classes sont exécutées pour une exécution donnée du code.

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 également la structure 101 pour identifier les endroits de l'architecture de votre base de code qui sont trop compliqués, afin que vous sachiez où se trouvent les vrais marais.

En théorie, vous ne pouvez pas trouver de manière déterministe du 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 de l'arrêt.

Cela peut se manifester dans le code Java de plusieurs manières:

• Chargement des classes en fonction de l'entrée utilisateur, des fichiers de configuration, des entrées de base de données, etc.
• Chargement de code externe;
• Passer des arborescences d'objets à des bibliothèques tierces;
• etc.

Cela étant dit, j'utilise IDEA IntelliJ comme mon IDE de choix et il dispose de nombreux outils d'analyse pour les dépendances de recherche entre les modules, les méthodes inutilisées, les membres inutilisés, les classes inutilisées, etc. balisé inutilisé mais une méthode publique nécessite une analyse plus approfondie.

Dans Eclipse, accédez à Windows> Préférences> Java> Compilateur> Erreurs / Avertissements
et remplacez-les tous par des erreurs. Corrigez toutes les erreurs. C'est le moyen le plus simple. La beauté est que cela vous permettra de nettoyer le code pendant que vous écrivez.

Capture d'écran du code Eclipse:

IntelliJ dispose d'outils d'analyse de code pour détecter le code non utilisé. Vous devriez essayer de rendre autant de champs / méthodes / classes que non publics que possible et cela affichera plus de méthodes / champs / classes inutilisés

J'essaierais également de localiser le code en double pour réduire le volume du code.

Ma dernière suggestion est d'essayer de trouver du code open source qui, s'il était utilisé, rendrait votre code plus simple.

La perspective de tranche Structure101 donnera une liste (et un graphique des dépendances) de tous les "orphelins" ou " groupes orphelins " de classes ou de packages qui n'ont aucune dépendance 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 peut faire ce que PMD et FindBugs ne peuvent pas faire . Je vais essayer.

PS Comme mentionné dans un commentaire ci-dessous, le projet vit maintenant dans GitHub .

Il existe des outils qui profilent le code et fournissent des données de couverture de code. Cela vous permet de voir (au fur et à mesure que le code s'exécute) combien il est appelé. Vous pouvez obtenir n'importe lequel de ces outils pour découvrir la quantité de code orphelin dont vous disposez.

• 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 des méthodes statiques publiques 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 réellement l'application à travers 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 qu'Emma, ​​Cobertura et Clover, instrumenteront votre code et enregistreront les parties de celui-ci qui seront 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. Il vous aidera à déterminer dans quelle mesure votre suite de tests couvre votre code.

Cependant, ce n'est pas la même chose que d'identifier un code mort réel. Il identifie uniquement le code couvert (ou non couvert) par les tests. Cela peut vous donner de faux positifs (si vos tests ne couvrent pas tous les scénarios) ainsi que de faux négatifs (si vos tests accèdent à du code qui n'est en fait jamais utilisé dans un scénario 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 en direct et d'analyser la couverture du code sur une longue période de temps.

Si vous exécutez dans un environnement redondant à charge équilibrée (et sinon, pourquoi pas?), Je suppose qu'il serait logique de n'instrumenter qu'une seule instance de votre application et de configurer votre équilibreur de charge de sorte qu'une partie aléatoire, mais petite, de vos utilisateurs s'exécutent sur votre instance instrumentée. Si vous effectuez cette opération sur une longue période (pour vous assurer que vous avez couvert tous les scénarios d'utilisation du monde réel - telles les variations saisonnières), vous devriez être en mesure de voir exactement quelles zones de votre code sont accessibles dans le cadre d'une utilisation réelle et quelles parties ne sont vraiment jamais accessibles et donc du code mort.

Je n'ai jamais personnellement vu cela, et je ne sais pas comment les outils susmentionnés peuvent être utilisés pour instrumenter et analyser du 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 - Dead Code Detector (DCD). Pour le code source, cela ne semble pas bien fonctionner, mais pour le fichier .jar - c'est vraiment bien. De plus, vous pouvez filtrer par classe et par méthode.

Netbeans est ici un plugin pour le détecteur de code mort Netbeans .

Il serait préférable qu'il puisse lier et mettre en évidence le code inutilisé. Vous pouvez voter et commenter ici: Bogue 181458 - Rechercher les classes, méthodes et champs publics inutilisés

Eclipse peut afficher / mettre en évidence du code qui ne peut pas être atteint. JUnit peut vous montrer la couverture du code, mais vous aurez besoin de quelques tests et devez décider si le test correspondant est manquant ou si le code est vraiment inutilisé.

J'ai trouvé l'outil de couverture Clover qui code les instruments et met en évidence le code utilisé et non utilisé. Contrairement à Google CodePro Analytics, il fonctionne également pour les applications Web (selon mon expérience et je peux me tromper sur 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'appels de méthode pour localiser les méthodes qui ne sont jamais appelées. Sur le graphique, vous trouverez des îlots de groupes 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.