Comment trouver du code inutilisé / mort dans les projets Java

https://stackoverflow.com/questions/162551

03-07-2019
|

Question

Quels outils utilisez-vous pour rechercher 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 toutefois de supprimer autant de code que possible non utilisé.

Les suggestions de stratégies / techniques générales (autres que des outils spécifiques) sont également appréciées.

Modifier : notez que nous utilisons déjà des outils de couverture de code (Clover, IntelliJ), mais ils ne vous sont d'aucune aide. Le code mort a toujours des tests unitaires et apparaît comme étant couvert. J'imagine qu'un outil idéal identifierait les groupes de code qui ont très peu d'autres codes, ce qui permet une inspection manuelle des documents.

La solution

Je demanderais au système en cours de fonctionnement de conserver des journaux d'utilisation du code, puis de commencer à inspecter le code non 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 lors de la création d'instances. Ensuite, un petit script pourrait comparer ces journaux à la liste complète des classes pour rechercher les classes inutilisées.

Bien sûr, si vous optez pour la méthode, vous devez garder à l’esprit les performances. Par exemple, les méthodes peuvent uniquement consigner leur première utilisation. Je ne sais pas comment cela se fait de mieux en Java. Nous l'avons fait dans Smalltalk, un langage dynamique qui permet donc de modifier le code au moment de l'exécution. Nous instrumentons toutes les méthodes avec un appel de journalisation et désinstallons le code de journalisation après la journalisation d'une méthode pour la première fois. Ainsi, après un certain temps, les performances ne sont plus pénalisées. On peut peut-être faire la même chose en Java avec des drapeaux booléens statiques ...

Autres conseils

Un plugin Eclipse qui fonctionne assez bien est le détecteur de code inutilisé .

Il traite un projet entier ou un fichier spécifique et affiche diverses méthodes de code inutilisé / mort, tout en suggérant des modifications de visibilité (c'est-à-dire une méthode publique pouvant être protégée ou privée).

CodePro a récemment été publié par Google avec le projet Eclipse. C'est gratuit et très efficace. Le plug-in a une fonctionnalité " Trouver le code mort " avec un ou plusieurs points d'entrée. (s) Fonctionne plutôt bien.

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

ProGuard est un logiciel gratuit de réduction de fichier de classe Java, d'optimisation, d'obfuscation,   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 fichiers non utilisés.   instructions. Il renomme les classes, champs et méthodes restants   en utilisant des noms courts sans signification. Enfin, il pré-certifie le traitement   code pour Java 6 ou pour Java Micro Edition.

Certaines utilisations de ProGuard sont les suivantes:


Création d'un 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 réduite   empreintes de pas.

Rendre les programmes et les bibliothèques plus difficiles à désosser.

Liste du code mort afin qu'il puisse être supprimé du code source.

Recibler et pré-certifier les fichiers de classe existants pour Java 6 ou supérieur, afin de tirer pleinement parti du chargement plus rapide de leurs classes.

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

Une des choses que je savais faire dans Eclipse, sur une seule classe, était de changer toutes ses méthodes en privé, puis de voir les plaintes que je recevais. 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 concernant les méthodes inutilisées, qui pourront 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.

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

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

Nous avons commencé à utiliser Rechercher des bogues pour nous aider à identifier une partie du funk dans la base de code de notre base de code environnement pour les refactorings. Je voudrais également envisager de Structure 101 d'identifier les zones trop compliquées de l'architecture de votre base de code. où se trouvent les vrais marais.

En théorie, vous ne pouvez pas rechercher le code inutilisé de manière déterministe. Il en est une preuve mathématique (enfin, c’est un cas particulier d’un théorème plus général). Si vous êtes curieux, cherchez le problème de l’arrêt.

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

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

Cela étant dit, j'utilise IDEA IntelliJ comme mon IDE de choix. Il possède de nombreux outils d'analyse pour les dépendances entre les modules, les méthodes inutilisées, les membres inutilisés, les classes inutilisées, etc. t appelé est étiqueté inutilisé mais une méthode publique nécessite une analyse plus poussée.

Dans Eclipse Allez sur Windows > Préférences > Java > Compilateur > Erreurs / Avertissements
et changez-les tous en erreurs. Corrigez toutes les erreurs. C'est le moyen le plus simple. La beauté est que cela vous permettra de nettoyer le code au fur et à mesure que vous écrivez.

Capture du code Eclipse:

IntelliJ dispose d’outils d’analyse de code permettant de détecter le code inutilisé. Vous devriez essayer de créer autant de champs / méthodes / classes que non-publics que possible et qui afficheront plus de méthodes / champs / classes inutilisés

Je voudrais aussi essayer de localiser le code en double afin de réduire le volume de code.

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

La Structure101 la perspective de la tranche donnera une liste (et graphe de dépendance) de n'importe quel "orphelin" ou " groupes orphelin de classes ou de packages ne dépendant pas de la " main " grappe.

DCD n’est pas un plugin pour certains IDE mais peut être exécuté à partir de ant ou autonome. Cela ressemble à un outil statique et il peut faire ce que PMD et FindBugs ne peuvent pas . Je vais l'essayer.

P.S. Comme indiqué dans un commentaire ci-dessous, le projet réside désormais dans GitHub .

Certains outils profilent le code et fournissent des données de couverture de code. Cela vous permet de voir (quand le code est exécuté) combien de fois 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 utilisable.

Cependant, aucune des deux méthodes statiques publiques ne sont pas utilisées dans un espace de travail. Si quelqu'un connaît un tel outil, merci de me le faire savoir.

Outils de couverture utilisateur, tels que EMMA. Mais ce n’est pas un outil statique (c’est-à-dire qu’il faut exécuter l’application au moyen de tests de régression et de tous les cas d’erreur possibles, ce qui est bien impossible :))

Malgré tout, EMMA est très utile.

Des outils de couverture de code, tels que Emma, ??Cobertura et Clover, instrumenteront votre code et enregistreront les parties de celui-ci qui seront invoquées par l'exécution d'une suite de tests. Ceci est très utile et devrait faire partie intégrante de votre processus de développement. Cela 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 vrai code mort. Il identifie uniquement le code couvert (ou non) par des tests. Cela peut vous donner des faux positifs (si vos tests ne couvrent pas tous les scénarios) ainsi que des faux négatifs (si votre code d'accès aux tests n'est en réalité jamais utilisé dans un scénario du monde réel).

J'imagine que le meilleur moyen d'identifier réellement le code mort consiste à instrumenter votre code avec un outil de couverture dans un environnement d'exécution en direct et à analyser la couverture de code sur une période prolongée.

Si vous travaillez dans un environnement redondant à charge équilibrée (et sinon, pourquoi pas?), alors je suppose qu'il serait logique d'instrumenter une seule instance de votre application et de configurer votre équilibreur de charge de manière aléatoire. , une partie de vos utilisateurs s’exécute 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 dans le monde réel, telles que les variations saisonnières), vous devriez être en mesure de voir exactement les zones de votre code accessibles en mode réel et les parties correspondantes. ne sont vraiment jamais accédés et donc du code mort.

Je ne l’ai jamais vu personnellement et je ne sais pas comment les outils susmentionnés peuvent être utilisés pour instrumenter et analyser le code qui n’est pas appelé 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 le fichier .jar, c'est vraiment bon. De plus, vous pouvez filtrer par classe et par méthode.

Netbeans , un plugin pour Netbeans détecteur de code mort .

Il serait préférable de pouvoir créer un lien vers et mettre en évidence le code non utilisé. Vous pouvez voter et commenter ici: Bug 181458 - Recherche des classes, méthodes et champs publics inutilisés

Eclipse peut afficher / mettre en évidence un code inaccessible. JUnit peut vous montrer la couverture de code, mais vous aurez besoin de quelques tests et devrez 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 surbrillance le code utilisé et non utilisé. Contrairement à Google CodePro Analytics, cela fonctionne également pour les applications Web (selon mon expérience et il se peut que je me trompe à 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 mappe d’appel de méthode afin de 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 par un point d’entrée principal.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow