La couverture du code met en évidence les méthodes non utilisées - que dois-je faire?
J'ai été chargé d'augmenter la couverture du code d'un projet Java Java existant.
J'ai remarqué que l'outil de couverture de code ( EclEmma ) a mis en évidence certaines méthodes qui ne sont jamais appelées de n'importe où.
Ma réaction initiale est non pas d'écrire des tests unitaires pour ces méthodes, mais de les mettre en évidence à mon supérieur hiérarchique/équipe et de demander pourquoi ces fonctions sont là pour commencer avec.
Quelle serait la meilleure approche? Faites-leur des tests unitaires ou demandez-vous pourquoi ils sont là?
- Supprimer.
- Commettre.
- Oublier.
Raisonnement:
- Le code mort est mort. Par sa description même, il n'a aucun but. Il a peut-être eu un but à un moment donné, mais cela a disparu et le code devrait donc disparaître.
- Le contrôle de version garantit que dans (d'après mon expérience)
rareévénement unique que quelqu'un vient plus tard à la recherche de ce code, il peut être récupéré. - Comme effet secondaire, vous améliorez instantanément la couverture du code sans rien faire (sauf si le code mort est testé, ce qui est rarement le cas).
Mise en garde des commentaires: La réponse originale supposait que vous aviez soigneusement vérifié que le code était, sans aucun doute, mort. Les IDE sont faillibles, et il existe plusieurs façons dont le code qui semble mort pourrait en fait être appelé. Faites appel à un expert, sauf si vous en êtes absolument sûr.
Toutes les autres réponses sont basées sur l'hypothèse que les méthodes en question sont vraiment inutilisées. Cependant, la question n'a pas précisé si ce projet est autonome ou une bibliothèque quelconque.
Si le projet en question est une bibliothèque, les méthodes apparemment inutilisées peuvent être utilisées en dehors du projet et leur suppression interromprait ces autres projets. Si la bibliothèque elle-même est vendue à des clients ou rendue publique, il peut même être impossible de retracer l'utilisation de ces méthodes.
Dans ce cas, il existe quatre possibilités:
- Si les méthodes sont privées ou privées du package, elles peuvent être supprimées en toute sécurité.
- Si les méthodes sont publiques, leur présence peut être justifiée même sans utilisation réelle, par souci d'exhaustivité des fonctionnalités. Ils devraient cependant être testés.
- Si les méthodes sont publiques et inutiles, leur suppression sera un changement de rupture et si la bibliothèque suit versioning sémantique , cela n'est autorisé que dans une nouvelle version majeure.
- Alternativement, les méthodes publiques peuvent également être dépréciées et supprimées ultérieurement. Cela donne un certain temps aux consommateurs d'API pour passer des fonctions obsolètes avant qu'elles ne soient supprimées dans la prochaine version principale.
Vérifiez d'abord que votre outil de couverture de code est correct.
J'ai eu des situations où ils n'ont pas repris les méthodes appelées via des références à l'interface, ou si la classe est chargée dynamiquement quelque part.
Comme Java est compilé statiquement, il devrait être assez sûr de supprimer les méthodes. Supprimer le code mort est toujours bon. Il y a une certaine probabilité qu'il y ait un système de réflexion fou qui les exécute en runtime, donc vérifiez d'abord avec d'autres développeurs, mais sinon supprimez-les.
Quelle serait la meilleure approche? Faites-leur des tests unitaires ou demandez-vous pourquoi ils sont là?
La suppression de code est une bonne chose.
Lorsque vous ne pouvez pas supprimer le code, vous pouvez certainement le marquer comme @ Déprécié , documentant quelle version majeure vous visez à supprimer la méthode. Ensuite, vous pouvez le supprimer "plus tard". Dans l'intervalle, il sera clair qu'aucun nouveau code ne devrait être ajouté qui en dépend.
Je ne recommanderais pas d'investir dans des méthodes obsolètes - donc pas de nouveaux tests unitaires juste pour atteindre les cibles de couverture.
La différence entre les deux est principalement de savoir si les méthodes font ou non partie de interface publiée . La suppression arbitraire de parties de l'interface publiée peut être une surprise désagréable pour les consommateurs qui dépendent de l'interface.
Je ne peux pas parler à EclEmma, mais d'après mes expériences, l'une des choses auxquelles vous devez faire attention est la réflexion. Si, par exemple, vous utilisez des fichiers de configuration de texte pour choisir les classes/méthodes auxquelles accéder, la distinction utilisée/inutilisée peut ne pas être évidente (j'ai été brûlé par cela plusieurs fois).
Si votre projet est une feuille dans le graphique des dépendances, le cas de dépréciation est affaibli. Si votre projet est une bibliothèque, l'argument de la dépréciation est plus fort.
Si votre entreprise utilise un mono-repo , alors la suppression est moins risquée que dans le cas du multi-repo.
Comme indiqué par l0b , si les méthodes sont déjà disponibles dans le contrôle de code source, les récupérer après la suppression est un exercice simple. Si vous étiez vraiment inquiet de devoir le faire, réfléchissez à la façon d'organiser vos commits afin de pouvoir récupérer les modifications supprimées si vous en avez besoin.
Si l'incertitude est suffisamment élevée, vous pouvez envisager de commenter le code , plutôt que de le supprimer. C'est un travail supplémentaire dans le chemin heureux (où le code supprimé n'est jamais restauré), mais il facilite la restauration. Je suppose que vous devriez préférer une suppression directe jusqu'à ce que vous ayez été brûlé par cela plusieurs fois, ce qui vous donnera un aperçu de la façon d'évaluer "l'incertitude" dans ce contexte.
question pourquoi ils sont là?
Le temps investi dans la capture du savoir n'est pas nécessairement perdu. J'ai été connu pour effectuer une suppression en deux étapes - d'abord, en ajoutant et en validant un commentaire expliquant ce que nous avons appris sur le code, puis en supprimant le code (et le commentaire).
Vous pouvez également utiliser quelque chose d'analogue à enregistrements de décisions architecturales comme moyen de capturer l'histoire avec le code source.
Un outil de couverture de code n'est pas omniscient, omniscient. Tout simplement parce que votre outil prétend que la méthode n'est pas appelée, cela ne signifie pas qu'elle n'est pas appelée. Il y a une réflexion et, selon la langue, il peut y avoir d'autres façons d'appeler la méthode. En C ou C++, il peut y avoir des macros qui construisent des noms de fonction ou de méthode, et l'outil peut ne pas voir l'appel. La première étape serait donc: Effectuez une recherche textuelle pour le nom de la méthode et pour les noms associés. Demandez à des collègues expérimentés. Vous constaterez peut-être qu'il est réellement utilisé.
Si vous n'êtes pas sûr, mettez un assert () au début de chaque méthode "inutilisée". Peut-être qu'on l'appelle. Ou une déclaration de journalisation.
Peut-être que le code est réellement précieux. Il peut s'agir d'un nouveau code sur lequel un collègue travaille depuis deux semaines et qu'il allait activer demain. Il n'est pas appelé aujourd'hui car l'appel va être ajouté demain.
Peut-être que le code est réellement précieux, partie 2: le code peut effectuer des tests d'exécution très coûteux qui pourraient trouver des problèmes. Le code n'est activé que si les choses tournent mal. Vous supprimez peut-être un outil de débogage précieux.
Fait intéressant, le pire conseil possible "Supprimer. Valider. Oublier." est la mieux notée. (Révisions de code? Vous ne faites pas de révisions de code? Que diable faites-vous de la programmation si vous ne faites pas de révisions de code?)
Selon l'environnement dans lequel le logiciel s'exécute, vous pouvez vous connecter si la méthode est appelée. Si elle n'est pas appelée dans un délai approprié, la méthode peut être supprimée en toute sécurité.
Il s'agit d'une approche plus prudente que de simplement supprimer la méthode et peut être utile si vous exécutez dans un environnement hautement sensible aux pannes.
Nous nous connectons à un #unreachable-code slack channel avec un identifiant unique pour chaque candidat à la suppression, et il s'est avéré assez efficace.