J'utilise des métriques de code dans mon travail dans de nombreuses situations:
En écrivant du code
L’utilisation la plus importante et peut-être la plus importante dans mon travail quotidien est Checkstyle , un outil destiné aux développeurs Java qui vérifie en permanence les métriques (entre autres) de mon code par rapport à un ensemble de règles que nous avons définies et marque les emplacements où mon code ne fonctionne pas. se conformer à ces règles. Au fur et à mesure que je développe du code, il me dit en temps réel si mes méthodes deviennent trop longues, complexes ou couplées, ce qui me permet de prendre du recul et de réfléchir à une refactorisation plus poussée.
Les développeurs sont totalement libres de casser toutes les règles car elles ne s'appliqueront jamais à toutes les situations. Les "règles" sont là pour stimuler la pensée et dire "Hé, est-ce la meilleure façon de faire cela?"
Pendant les revues de QA / Code
La première chose que je fais généralement lorsque j'effectue une révision de code est de vérifier la couverture de code du code que je vérifie conjointement avec un outil de couverture de code qui met en évidence les lignes de code couvertes. Cela me donne une idée générale de la profondeur du code de test. Peu m'importe que la couverture soit de 20% ou de 100% tant que le code important est bien testé. Ainsi, le pourcentage couvert ne veut rien dire, mais 0% se démarque comme un pouce endolori que je veux examiner avec soin.
Je vérifie également les métriques acceptées par l'équipe qui ont été "cassées", le cas échéant, pour voir si je suis d'accord avec le développeur pour dire que c'était OK ou si je peux suggérer des moyens de l'améliorer. Le fait de convenir de ces paramètres de développement au sein de notre équipe pour la rédaction d'un nouveau code a grandement contribué à l'amélioration de notre code. Nous écrivons beaucoup moins de méthodes monolithiques et sommes beaucoup mieux au principe de responsabilité unique maintenant.
Améliorations apportées au code hérité
Nous aimerions améliorer beaucoup de code hérité. Les métriques à tout moment sont relativement inutiles, mais ce qui est important pour nous, c'est que plus la couverture de code temporel est élevée, plus la complexité et le couplage diminuent. Par conséquent, nos métriques sont connectées à notre serveur d'intégration continue, ce qui nous permet d'analyser le temps pour nous assurer que nous sommes sur la bonne voie.
Se familiariser avec une nouvelle base de code
La seule fois où j'utilise des lignes de métrique de code source est lorsque je regarde une base de code que je ne connais pas bien. Cela me permet de jauger rapidement la taille approximative du projet par rapport aux autres avec lesquels j'ai travaillé. En utilisant d'autres indicateurs, je peux également avoir une idée plus précise de la qualité du projet.
Les éléments clés sont d’utiliser les métriques comme points de départ pour les tendances, les discussions ou les voies à suivre et de ne pas les gérer religieusement pour obtenir des chiffres exacts. Mais je crois fermement qu’ils peuvent vous aider à améliorer le code qui vous convient s’il est utilisé correctement.