Dette technique – Partie 2 – Repérage

radar-icon1.pngDans le précédent billet (Dette technique – partie 1), j’expliquais les concepts de base reliés à la notion de dette technique. Malgré qu’il est primordial de bien comprendre les concepts, il est tout aussi important de développer les réflexes pour la repérer dans une application. Voici quelques éléments qui peuvent servir dans ce contexte.

Indicateurs d’équipe

https://i2.wp.com/www.pngall.com/wp-content/uploads/2016/07/Team-Work-PNG-Pic.pngVoyons les principaux indicateurs qui permettront de soupçonner une dette technique trop importante :

1- Baisse de la vélocité

La baisse de la vélocité d’une équipe de réalisation agile se traduit par moins de valeur pour le client à chaque itération. Bien qu’il y ait plusieurs facteurs pouvant amener à ce constat, la dette technique est souvent un problème. Comme les développeurs doivent passer plus de temps à comprendre le code auquel ils font fasse, ils perdent en productivité. Les changements sont aussi plus difficiles à effectuer sans effets de bord, ce qui allonge les essais requis pour stabiliser l’application. Le pire dans ce contexte, c’est qu’un climat de peur peut s’installer et les modifications pour améliorer la qualité du code se feront de plus en plus rares. En SCRUM, on remarquera une baisse de la quantité de points livrés à chaque sprint de manière graduelle. Il faut donc rester vigilant !

2- Taille de l’équipe

Parfois, la vélocité de l’équipe demeurera inchangée, mais la taille de l’équipe aura tendance à grandir. Typiquement, on voit des équipes qui demandent un testeur de plus parce que la quantité de tests de non-régression à faire augmente. Il est d’ailleurs anormal d’avoir à tester l’ensemble de l’application à chaque modification. Encore une fois, le climat de peur dans l’équipe pousse les testeurs à tout tester pour éviter des problèmes en production.

3- Temps moyen de correction d’anomalie

Semblable à la baisse de vélocité de l’équipe, le temps de correction moyen nécessaire pour régler une anomalie peut parfois augmenter. Bien que les anomalies ne soient pas toutes de même nature, il demeure important de surveiller ce point. Peut-être que les nouvelles fonctions de l’application se livrent facilement, mais qu’on a de la difficulté à corriger les problèmes dans le code existant…

4- Nombre de bogues connus

Si le nombre de bogue connu dans une application tend à augmenter, c’est très mauvais. Si les bogues ne sont pas importants et ne seront pas corrigés, alors pourquoi les documenter? Pour les bogues qui doivent être corrigés, il est important de ne pas les repousser dans le temps, car les intérêts de la dette s’accumulent. De plus, les corrections apportées auront probablement de l’impact sur les nouvelles fonctionnalités. Les coûts augmenteront de manière exponentielle ! Faire l’autruche, ça ne fonctionne jamais !

5- Délais jugés anormaux

Tout délai de réalisation jugé anormal peut être un symptôme de dette technique. Avec un peu de recul, on s’aperçoit que les modifications demandées par notre client ne devraient pas prendre autant de temps. Il est alors judicieux de se consulter en équipe pour déterminer ce qui ne tourne pas rond. Peut-être que les nouveaux besoins d’affaire ne cadrent pas bien avec l’architecture en place et ça peut être normal. Une décision s’impose : continuer dans ce sens ou prendre le temps d’adapter le code pour les nouveaux besoins ?

 

Mesures automatiques

Avec les outils évolués dont nous disposons aujourd’hui, il est relativement facile de détecter de manière automatiques certains symptômes de dette technique. Pour d’autres problèmes, c’est plus difficile.

Analyse statique de code

Magnifier Free IconCe type d’analyse peut être fait à l’aide d’outils qui analysent le code de manière statique, donc pas à l’exécution. Les code source est passé au crible pour trouver des éléments qui mènent à la dette technique. Les outils suivants permettent d’analyser des métriques de manière statique :

  1. Roslyn Analyzers
  2. FxCop
  3. ReSharper
  4. NDepend
  5. SonarLint
  6. Visual Studio
  7. Compilateur (Avertissements)

On peut configurer ces outils pour faire ressortir les problèmes qui sont importants pour nous. Par exemple, une règle FxCop existe pour éviter d’exposer des listes génériques qui ne sont pas en lecture seule dans les méthodes publiques (CA2227). Si on développe un API vendu commercialement qui est consommé par des milliers d’utilisateurs, c’est très important. Si on est en train de développer un ViewModel dans une application WPF, c’est d’une importance relative.

Voici les métriques qui à surveiller :

  1. Complexité cyclomatique
  2. Index de maintenabilité
  3. Règles FxCop, SonarLint, StyleCop, etc.
  4. Nombre d’avertissements du compilateur

Couverture de code

Darth Vader inspirational poster with caption “Testing: I find your lack of tests disturbing”.Dans le même ordre d’idée, la couverture de code effectuée par les tests automatisés est aussi un bon indicateur. Sans viser le 100% dans tous les contextes, il est intéressant de surveiller la tendance. Est-ce qu’on augmente notre couverture sur les dernières itérations ou si elle diminue? Une application sans tests automatisés ne pourra pas évoluer sans risque. Il faudra des gens pour effectuer les essais et le travail deviendra de plus en plus difficile avec les années. Les équipes que j’ai côtoyé dans le passé ont tendance à éviter de toucher au code qui n’est pas concerné par une demande d’un client. Les principes du refactoring deviennent donc très difficiles à appliquer.

Dangers

Ne devenez pas esclaves de vos mesures ! Parfois, il peut être nécessaire de violer une règle qu’on s’est donné. C’est le gros bon sens qui doit l’emporter ! Il est aussi important de noter qu’il faut utiliser les métriques de manière responsable parce qu’on peut avoir des faux-positifs lors de la détection avec la plupart des outils énumérés.

Violer un principe SOLID n’est pas nécessairement mauvais. Ne pas savoir qu’on le viol est mal !

Et comment repérer les autres problèmes ?

Certains éléments sont difficilement mesurables… Comment évaluer le respects des principes SOLID ou le design d’une application ? Pas évident ! La meilleure réponse que j’ai trouvé à ce sujet et de le faire en équipe. Lorsque tout le monde a peur d’une classe ou d’un composant, il devient important d’en parler. Facilement, on peut en venir à évaluer le temps nécessaire à la correction d’une partie de la dette. D’autres éléments peuvent être considérés comme :

  • Code smells
  • Capacité d’adaptation du code
  • Couplage
  • Design
  • Capacité à répondre aux besoins d’affaires (courants et futurs)

 

Conclusion

La question que tout le monde se pose quand on prends connaissance d’une dette c’est : combien je dois rembourser ? Pour le domaine financier, c’est facile. Pour le logiciel, ça l’est moins. Dans le prochain billet, je présenterai une technique d’évaluation ou de mesure de la dette technique permettant de la quantifier. Stay tuned!