4.0 Introduction à la Partie 4 : Métriques de code et de qualité

Les Parties 2 et 3 ont mesuré comment le travail se déplace et comment se portent les personnes qui le produisent. Cette partie se tourne vers l’artefact lui-même : le code, et ce qu’une métrique peut et ne peut pas vous dire sur sa qualité. Les métriques de qualité de code ont la plus longue histoire de toute famille de métriques de ce livre, la complexité cyclomatique remonte à 1976, et l’histoire de mauvais usage la plus longue qui l’accompagne. Cette partie traite cette histoire sérieusement : chaque sujet nomme un signal authentiquement utile aux côtés de la manière spécifique et bien documentée dont ce signal se fait manipuler une fois qu’il devient une cible.

Le fil conducteur reliant ces six sujets est qu’aucune métrique de code unique ne capture la qualité à elle seule, et plusieurs des plus populaires induisent activement en erreur quand poursuivies isolément. Un pourcentage élevé de couverture de test peut coexister avec des tests qui ne vérifient rien de significatif. Un score de complexité bas peut coexister avec un code techniquement simple mais conceptuellement incohérent. Les sujets de cette partie associent chacun leur métrique vedette au contrôle complémentaire qui attrape son angle mort spécifique : la complexité avec le contexte de maintenabilité, la couverture avec le test de mutation, le churn avec l’analyse de points chauds, l’analyse statique avec le jugement humain, et la dette technique avec une remédiation priorisée plutôt qu’un arriéré sans cesse croissant et délaissé.

Pour les grandes équipes, les métriques de code et de qualité sont ce qui rend possible la gestion d’une base de code trop grande pour qu’une seule personne la garde en tête. Une équipe de cinq personnes peut s’appuyer sur une connaissance tacite partagée de quelles parties du système sont fragiles ; une organisation de cinq cents ingénieurs couvrant des dizaines de services a besoin de signaux instrumentés pour trouver cette fragilité systématiquement. Les organisations de grande entreprise et de gouvernement, portant souvent des bases de code mesurées en décennies plutôt qu’en années, dépendent des métriques de cette partie pour prioriser où un investissement de maintenance limité fera le plus de bien.

Sujets de cette partie

4.1 Métriques de complexité de code : la complexité cyclomatique et ses apparentées, ce qu’elles prédisent réellement, et leur risque de manipulation bien documenté.
4.2 Couverture de test et efficacité des tests : pourquoi un pourcentage de couverture seul vous dit moins qu’il n’y paraît, et comment le test de mutation comble l’écart.
4.3 Churn de code et analyse de points chauds : trouver la fraction spécifique et restreinte d’une base de code responsable d’une part disproportionnée des défauts et du coût de maintenance.
4.4 Analyse statique et métriques d’odeurs de code : signaux automatisés de qualité de code, leur valeur réelle et leurs limites face au jugement humain.
4.5 Mesure de la dette technique : transformer un passif invisible et discuté de manière informelle en un portefeuille visible, priorisé et gérable.
4.6 Métriques de documentation et de connaissance : mesurer si la documentation aide réellement, pas seulement si elle existe.

Comment ces sujets s’articulent

Ces six sujets se construisent de la plus petite unité de code vers l’extérieur. Le sujet 4.1 commence au niveau d’une fonction ou méthode unique ; le sujet 4.2 demande si les tests vérifient réellement le comportement de cette unité ; le sujet 4.3 prend du recul pour trouver quels fichiers et modules à travers toute la base de code méritent l’attention en premier ; le sujet 4.4 ajoute la couche d’outillage automatisé qui scanne continuellement tout cela ; le sujet 4.5 transforme les constats accumulés des quatre premiers en un arriéré géré et priorisé plutôt qu’une inquiétude diffuse et non adressée ; et le sujet 4.6 clôt la partie en mesurant si la connaissance nécessaire pour maintenir tout cela en sécurité est réellement documentée et trouvable.

Cette partie se relie directement aux métriques de stabilité de la Partie 2 : le taux d’échecs de changement (sujet 2.10) est, en grande partie, une conséquence en aval de la qualité de code que cette partie mesure en amont. Elle se relie aussi en avant aux métriques de produit de la Partie 5, puisque les défauts échappés (sujet 5.1) sont fréquemment traçables exactement aux points chauds de complexité et aux lacunes de couverture que cette partie est construite pour faire émerger avant qu’ils n’atteignent la production.