Java et detection du code mort

Bonjour,

je viens d'hériter d'un assez gros projet en java (800 000 lignes de code). Nous suspectons d'avoir pas mal de code mort mais nous avons des difficultés pour l'identifier. Mon but est de me consacrer aux méthodes PUBLIC non utilisées dans un premier temps.

1. Nous avons en fait 400 projets Eclipse avec des dépendances dans tous les sens. Chaque projet est généré Le résultat est qu'Eclipse n arrive pas à ouvrir tous les projets en même. Des outils d'analyse de code mort sont dc impossible.
2. Nous avons pour quasiment chaque méthode des TUs associés. C est super mais si la méthode n'est pas utilisé, elle reste qd même non détecté en tant que code mort puisqu'elle est référencé. La bonne nouvelle est que tous les TUs sont un fichier appellé *test*.java.

Je suis nouveau dans le monde java et je voudrais savoir s'il y a des outils permettant de détecter le code mort dans des cas pareils.
J'envisage sinon une manière assez brutal de recherche. Pour chaque méthode public, je les change en private et je regarde si la compil passe ou pas (en excluant la partie TU). Si la compil passe ca veut dire que la méthode n'est pas référencée. Si elle ne passe pas, je sais que la méthode est référencée.
L'approche est assez lourde mais je pense que ca marche. Avez vous des conseils ou une approche plus simple.

MErci

Et comment ça se passe le build de tout ça ? Il n'y a aucune plateforme d'intégration continue type Jenkins en place ? Personnellement je t'orienterais vers Sonar. Couplé avec un Jenkins, tu aurais une analyse assez complète je pense.

Et concernant ton mode d'approche je dirais qu'il est assez risqué. Avoir un code qui compile n'est pas synonyme d'une application qui fonctionne. Donc tu n'auras aucune garantie d'avoir induit des régressions que tu ne sais pas identifier.

Je te rassures il y a plusieurs approches : Verticales (top-down ou bottom-up), environnementales, scenario de dépyramidage
Déjà pour le build, utilises-tu Maven ?

Merci pour vos réponses

pour le build nous sommes entrain de passer sous Gradle. Ca va nous permettre d'un peu mieux maitriser nos dépendances.

Je suis interessé par les différents types de méthodes ...

Ok john,

Je dois t'avouer que je ne connais pas gradle car à l'époque où j'avais regardé, il proposait de faire des trucs sympa mais tout était en groovy et je n'avais pas envie de me mettre à ce langage :? (bon ok j'avais la flemme).

Si ton projet est déjà mavenisé, tu peux faire une analyse avec sonar pour identifier ton code mort.
Si ça trouve tu vas pouvoir te délester de 30% de ton code ;)

Si ton projet ne l'est pas (mavenisé) heu ....... t'es un peu dans la m_-_-_-e parce que presque 0.8 million de lignes sans un outil de build :oops:

Supposons que tu en sois là. c'est un peu comme dans le sketch de Biggard, la chauve-souris t'en veut personnellement. Elle t'a ciblé :lol: .
Mais bon tu as encore un peu d'espace pour t'en sortir grâce à tous tes TU qui te permettront d’alléger le volume de ton source et de pouvoir ainsi ouvrir l'ensemble allégé des TU dans Eclipse. Et là tu fais un coup de codepro pour détecter ton code mort.

Loin d'être un travail trivial si vous partez d'une approche bottom-up :

- https://developers.google.com/java-d...wnload-codepro, Codepro semble s'arrêter à Eclipse Indigo : quelqu'un à réussi à l'utiliser avec un version plus récente ? (voir https://marketplace.eclipse.org/cont...depro-analytix …)
- l'analyse de couverture avec SONAR va vous amener dans les plaisirs de l'installation de JaCoCo dans un projet maven avec tous les problèmes de compatibilité entre versions des plug-ins Maven, du plug-in JaCoCo et du serveur SONARQUBE lui-même...
sans parler des bugs de certains outils d'analyse de byte code pas encore à jour et qui ne reconnaissent pas quelques séquences de code générées par certains compilateurs récents (dont AspectJ) et qui vont générer des fausses alertes en pagaille (du genre "Redundant nullcheck of this, which is known to be non-null in" sur un return d'une valeur locale à la fin d'une méthode... ou encore plus amusant "Dead store to $L0" à l'entrée de certaines méthode static...)
… et sans perdre de vue que tout ce qui sera signalé comme code mort ne l'est pas nécessairement vraiment, d'abord parce que dans un projet de cette taille il est certain que les test unitaires ne couvrent pas 100% du code, que tout ce qui peut dépendre de circonstances liées à l'environnement ne peut pas toujours être testé statiquement, tout code liée dynamiquement risque de passer inaperçu (que ce soit des scripts ou des jars chargés dynamiquement…), etc.


A votre place je partirais en top-down :
de l'analyse fonctionnelle, extraire ce qui est encore utilisé et commencer par enlever le dead-code de haut niveau, vous verrez déjà plus clair dans la structure générale du code
De plus vous pouvez arrêter le processus quand vous estimerez avoir atteint un niveau de nettoyage suffisant, car plus vous descendrez plus vous serez dans des couches "utilitaires" dont le nettoyage sera de moins en moins rentable...
et de plus en plus "risqué"...

Merci pour vos réponses en tout cas.

Je vois que le problème n'est pas simple et je voulais déjà passer par une méthode sans trop d analyse à vrai dire.
Je vais essayer ma méthode brutale en changeant les méthodes public en private plugin par plugin et en recompilant le tout. Je sais qu'il y a des limites à l'exercice (le temps) mais si je peux déjà dégager une partie du code comme ca, ca sera bien.
Le reste se fera par analyse fonctionnelle.

Je vous tiens au courant car je ne pense pas que je sois le seul avec cette problématique.

Citation:

---

Envoyé par JohnJavaDoe

Je vais essayer ma méthode brutale en changeant les méthodes public en private plugin par plugin et en recompilant le tout. Je sais qu'il y a des limites à l'exercice (le temps) mais si je peux déjà dégager une partie du code comme ca, ca sera bien.
Le reste se fera par analyse fonctionnelle.

---

Je déconseille vraiment cette façon de faire. A travers ce sujet, tu as eu plusieurs pistes de départ. A ta place, je prendrais le temps de mettre en place l'une ou l'autre de ces façons de faire.