Quantifier et suivre la dette technique

Code de bonne qualité : quantifier la dette technique

Quand on fait trop d'entorses aux bonnes pratiques de développement, la qualité du code se dégrade ce qui ralentit la vitesse de développement : on passe plus de temps à tenter de comprendre son code et à en corriger les bugs que de développer les fonctionnalités. Il faut ainsi payer en temps de travail supplémentaire le coût du code de mauvaise qualité. La mauvaise qualité représente la dette technique, et le travail supplémentaire en sont les intérêts.

D'où vient-elle ? Et bien par exemple lorsque vous avez une échéance et il se trouve que le projet est un peu en retard. Pour être à l'heure vous codez dans l'urgence et avec les pieds. Ce code de mauvaise qualité engendre de la dette technique.

Tout développeur (et chef de projet) devrait connaître ce concept. Mais, peut-on la mesurer précisément ? Il est facile de dire, "le projet est dégueux" ou "j'ai de la dette" mais je n'ai encore jamais entendu dire  : "j'ai 2000 € de dette technique" ou "j'ai 15 jours de dette technique". Or sans mesure quantitative, la dette technique reste un concept abstrait et peu applicable.

Dans cet article je vais vous proposer plusieurs méthodes et un outil pour estimer quantitativement la dette technique d'un projet.

Méthode de mesure

Il est possible de mesurer la dette technique en points, en jour homme ou en monnaie monnaie. Les jours-homme ou l'argent ont l'avantage d'être bien plus parlants et concrets, notamment pour des personnes non techniques. Pour les fans des méthodes agiles, vous pouvez attribuer des points correspondants au points de stories.

Attention, mesurer la dette technique en argent ou jour-homme revient à estimer combien de temps il faudrait pour rembourser la dette en nettoyant le code. Or faire des estimations est souvent un exercice périlleux. Plutôt que de proposer une valeur, il peut être plus judicieux de proposer une limite basse (ou borne inférieure) à l'estimation : "j'ai au moins 3 jour-Homme de dette technique" ou "j'ai au moins 2000 € de dette technique".

Méthode 1 : Méthode simple mais manuelle

L'idée est d'indiquer par des commentaires, comme @debt dans le code les zones endettées. Un outil va ensuite parser les mentions et générer un score selon les règles que vous avez établi. Le plus simple consistant à attribuer 1 point par mention @debt. 

Le développeur qui annote doit néanmoins pouvoir estimer que le code qu'il produit génère de la dette, ce qui peut être délicat pour un junior. Une solution est de confier ça à développeur expérimenté qui peut lui indiquer les zones du code générant de la dette lors d'une revue de code ou pendant une merge request.

Scenario : vous avez une urgence, vous codez un module de manière sale (c'est ok) mais vous le savez. Vous ajoutez donc un commentaire dans le code "@debt("code duplication"). Si vous êtes n'êtes pas trop dans le rush vous lui affectez aussi une estimation du nombre de jours qu'il vous faudrait à froid pour le coder proprement. 

Les annotations peuvent être extraites par un outil qui extrait les annotations du projet à l'aide d'expression régulières

On peut aussi envisager de nommer les foncions et méthodes "sales" en mettant debt dedans afin de rendre explicite que la fonction génère de la dette. 

Méthode 2 : utiliser des outils pour la qualité de code

La méthode manuelle a l'avantage d'être souple mais elle demande de l'implication des équipes. Il peut ainsi être intéressant de faire appel à des outils de qualité de code automatiques pour mesurer la dette technique tels que des analyseurs statiques de code, de formatage et de suivi de convention ou decode dupliqué.

Chaque problème détecté par un outil peut alors contribuer à un score de dette. Par exemple,  On pourrait imaginer qu'on attribue 1 point par problème relevé par l'analyseur de code et 3 points par duplication de code et en faisant ça on définit une échelle de dette. 

Il est possible de mesurer la dette en mélangeant l'approche manuelle avec les outils automatiques. 

L'échelle de dette

L'idée est d'attribuer des points, des jour-Hommes ou des coûts pour chaque aspect de la dette. Cette échelle est définie soit par l'équipe soit par le référent de l'équipe. La clarté et la non redondance sont deux propriété importantes de cette échelle. 

Vous pouvez aussi envisager des règles plus complexes où le nombre de points dépend de la situation. Si vous comptez comme de la dette une fonction trop grosse, il est possible d'attribuer 1 point de dette à chaque fois que la fonction est utilisée. En effet il faudra bien modifier le code de la fonction et l'ensemble des bouts de code y faisant appel. Cela demande un outil un peu élaboré qui récupère à la fois les mentions de dette et peut faire de l'analyse de code.

Il est possible d'attribuer des points pour chaque type de problème détecté par les outils automatiques et créer une échelle qui contiendrait des scores pour les annotations manuelles et automatique. Par exemple on pourrait affecter :

   - 1 point par problème détecté par l'analyse statique de code

   - 1 point détecté par l'analyse de convention de codage

   - 3 points détecté par code dupliqué

Mise en place et avantages

Quelque soit la méthode choisie pour cartographier la dette et l'échelle choisie, mettre en place une approche quantitative permet à un référent de disposer d'une métrique pour suivre l'évolution de la dette technique et la gérer. Ce n'est plus un concept abstrait , c'est un outil de pilotage de projet. Il peut décider de l'augmenter temporairement en cas de besoin ou prévoir des sessions de re-factoring si elle commence a être trop élevée.

Quant à la mise en place, je dirais qu'il ne sert à rien de vouloir être parfait dès le début. Il vaut mieux mettre en place une première méthode même imparfaite que de se lancer dans un chantier qui ne verra jamais le jour. L'existence de ce premier outil donnera envie naturellement d'être amélioré. 

Alors existe-t-il des outils pour faire cela ? 

Je ne connais pas d'outil dédié néanmoins il semble que sonarkube propose des outils pour la dette technique.

J'ai développé techdebt, un outil qui reprend les principes de cet articles pour annoter, quantifier et suivre la dette technique. Disponible sur ce dépôt git : https://github.com/lcetinsoy/tech-debt

Liens : 

https://julien.duponchelle.info/python/detect-python-code-duplicate

https://github.com/sebastianbergmann/phpcpd