BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Gérer votre Dette Logicielle

Gérer votre Dette Logicielle

La dette logicielle existe sous différentes formes. La dette technique, largement connue, et d'autres formes comme la dette de compétence ou de qualité. La dette logicielle peut causer une augmentation des coûts de maintenance du produit et peut déprimer les développeurs. Plusieurs solutions existent pour la gérer.

Dans l'article L'autre type de dette logicielle, Niklas Björnerstedt parle de la "dette de compétence". Il la définit comme :

L'écart entre ce qu'il y a dans votre code et ce que vous en comprenez.

Pour garder une faible maintenance logicielle, il faut faire attention à la fois à la dette technique et à la dette de compétence, comme Niklas l'explique :

Comme la dette technique grandit inexorablement avec le temps, à moins que vous ne la combattiez, la dette de compétence fait de même. La plus grosse différence entre ces deux types de dettes est que plus vous changez le code, plus la dette technique croît, tandis que la dette de compétence croît lorsque vous arrêtez de le changer ! Cette dernière est donc un problème plus profond dans les systèmes matures où le développement actif est terminé.

Niklas propose deux techniques qui peuvent être utilisées pour réduire votre dette : programmer à deux et refactorer le code :

Pour moi, la vraie valeur du pair programming est la réduction à la fois de la dette technique et de la dette de compétence. En travaillant par paire, les membres de l'équipe élargissent les parties du code qui leur sont familières et améliorent l'imbrication. De manière similaire, la valeur du refactoring n'est pas uniquement la réduction de la dette technique. Le refactoring est un bon moyen de réduire également la dette de compétence. C'est seulement quand on peut changer un système qu'on le comprend vraiment.

Quand la dette de compétence croît, les efforts nécessaires à la maintenance des systèmes augmentent, jusqu'au point où les entreprises considèrent l'option de remplacer le système :

Les gens diront que l'ancien système était impossible à maintenir alors que le vrai problème était qu'ils ne comprenaient pas son fonctionnement. Oui, la dette technique a aggravé les choses puisque le code peu clair et le manque de tests automatisés ont rendu la compréhension du système frustrante. La volonté de réécrire arrive typiquement quand trop peu des développeurs originaux sont encore là et que le métier n'est pas capable de trouver de nouveaux développeurs qui sont capables, ou qui ont envie, d'apprendre.

Mike Hustler a écrit un article sur la manière la plus agile de gérer la dette technique, dans lequel il traite de la manière d'équilibrer les capacités de développement du produit et la gestion de la dette technique. Il explique comment passer des produits à une équipe de maintenance peut conduire à l'augmentation de la dette technique et de compétence :

J'ai vu des entreprises monter une équipe de maintenance séparée qui fait, par exemple, la taille de la moitié de l'équipe de développement. De mon point de vue, c'est la mauvaise approche (au moins pour la taille des équipes avec lesquelles on travaille). (...) Le suivi qui découle de l'appropriation est perdu car quelqu'un d'autre s'occupe des bugs créés par une personne différente, qui est en fait une autre équipe. Sans une solide communication, la trame de fond de pourquoi une certaine approche initiale a été choisie est perdue. La connaissance du domaine n'est pas présente, donc l'efficacité dans la résolution des problèmes est réduite. Encore pire, j'ai vu des équipes de maintenance composées de développeurs moins expérimentés qui avaient des problèmes pour identifier la source des erreurs, resultant en des corrections légères là où une refonte aurait été préférée.

La dette technique déprime les développeurs et peut les décider à partir, ce qui augmente la dette de compétence, comme Cory House le décrit dans sa publication 7 raisons de nettoyer les problèmes de code :

Ecrire du code négligé ou pas clair injecte de la dette technique dans vos projets. Et même si la dette technique peut être utile quand elle est considérée prudement dans un contexte, une dette technique excessive est déprimante et conduit le talent hors de l'entreprise. Lorsque ce qui est simple devient compliqué, les développeurs commencent à tourner le dos et à aller voir ailleurs. Ils tirent plus de satisfaction de la qualité de leur travail que de la quantité. La dette technique diminue les chances de réutilisation et met la barre basse pour la qualité du reste du code.

David Hammerslag a écrit l'article Vous voulez de la prédictabilité ? Evitez la dette de qualité, dans lequel il parle des effets de la non-résolution des anomalies trouvées dans le code. Sa définition de la dette de qualité est :

La Dette de Qualité est une mesure de l'effort nécessaire à la résolution des anomalies existantes dans le produit logiciel à tout instant.

Il compare la dette de qualité et la dette technique :

La dette technique est une mesure de la qualité de la conception et du code, qui est à l'intérieur de la qualité du logiciel. La dette de qualité est une mesure de la qualité externe du code, ce que l'utilisateur voit et utilise. Un utilisateur ne voit jamais (directement) la dette technique.

Un programme peut ne contenir aucune dette de qualité et avoir une énorme dette technique. Il peut implémenter correctement tous les besoins et les fonctionalités attendues, et tourner sans problème. Sa dette technique est peut-être énorme, mettant en avant chaque mauvaise conception et implémentation logicielle que vous pouvez imaginer. D'un autre côté, la meilleure conception et le code le plus incroyablement élégant peuvent toujours produire les mauvais résultats ou des fonctionnalités manquantes.

La dette de qualité ne devrait pas être ignorée, comme l'explique David :

La Dette de Qualité est plutôt comme une dette financière : plus elle est ancienne, plus elle est difficile à payer. Dans le pire des cas, un projet met de côté les tests en attendant que le développement soit fait. Il est bien connu que, plus on attend pour corriger une anomalie, plus c'est difficile. Si de nombreuses anomalies persistent (connues comme inconnues), l'effet est exacerbé, les anomalies en masquent d'autres, et les corrections impactent le même code.

David suggère plusieurs pratiques agiles qui peuvent être utilisées pour gérer les anomalies et conserver une faible dette de qualité :

  • Definition of Done
  • Behavior Driven Development / Tests fonctionnels automatisés
  • Intégration continue
  • Tests automatisés
  • Ne pas tolérer de "fonctionnalités cassées"

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT