Les bogues font-ils partie de la dette technique ?
-
29-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Notre Scrum Master ne cesse de qualifier les bogues de dette technique.A-t-il raison, les bugs sont-ils considérés comme de la dette technique dans le monde Agile ?
La solution
Je pense que la réponse ici est assez simple - la principale caractéristique de la dette technique est que c'est quelque chose que nous encourons par choix.
Nous choisissons de prendre des décisions d'architecture, de conception ou de mise en œuvre qui, selon nous, nous causeront des problèmes plus tard afin d'atteindre des objectifs spécifiques plus tôt.
Un bogue n'est pas quelque chose que nous choisissons d'avoir dans notre code - donc de facto ce n'est pas une dette technique.
Bien sûr, on peut faire toutes sortes d'arguments intéressants (et éventuellement valables) sur les choix faits après la découverte, mais fondamentalement (et en particulier dans le contexte de la question) non, les bogues ne sont pas une dette technique - cela ressemble plus à un abus de bingo à la mode pour moi.
En tant que post-scriptum - je ne suis pas d'accord avec l'affirmation selon laquelle il est certain que la dette technique conduira à des bogues en soi, car cela fait beaucoup d'hypothèses sur la nature des choix effectués.Par exemple, vous pouvez avoir un code bien écrit, bien structuré et couvert par des tests qui fait encore - disons - des compromis architecturaux pour une livraison précoce.De même, vous pouvez choisir de ne pas automatiser vos processus de déploiement, ce qui n'entraînera pas de bogues, mais entraînera probablement beaucoup de stress et de douleur.Bien sûr, si la dette est que vous avez écrit du code qui n'est pas SOLIDE (ou autre), alors oui... mais ce n'est en aucun cas toujours le cas.
Autres conseils
Oui.
La dette technique (également connue sous le nom de dette de conception ou dette de code) est une métaphore néologistique faisant référence aux conséquences éventuelles d'une architecture logicielle médiocre ou évolutive et du développement de logiciels au sein d'une base de code.
Provenance : Wikipédia
Considérez la dette technique comme quelque chose que vous auriez pu éviter en ayant un meilleur flux de travail (par exemple, faire correctement l'architecture avant de passer au codage, faire du TDD, etc.), de meilleures pratiques de codage, etc.
La plupart des bogues auraient pu être évités par un examen supplémentaire ou l'utilisation de méthodes plus formelles.En ne faisant pas tout ce que vous pouvez pour ne pas avoir de bugs en premier lieu, vous réduisez le coût immédiat/à court terme du projet, mais augmentez la dette technique.
Après avoir lu la réponse de BЈовић, je vois que ce n'est peut-être pas aussi facile que je le pensais.
Par exemple, l'article Les bugs font-ils partie de la dette technique ? affirme que seuls les bogues que vous connaissez mais que vous avez décidé de ne pas corriger font partie de la dette technique.
Un autre exemple, Réflexions de Christopher sur la dette technique qualifie les bogues comme le résultat d'une dette technique, et non comme une partie de celle-ci.Cela étant dit, de nombreux résultats répertoriés, tels que "le coût de mise en œuvre d'une nouvelle fonctionnalité", sont influencés par le nombre de bogues.
Enfin, lors de la création de Modèle ABCDE-T de la dette technique, j'ai inclus les bogues comme l'un des six facteurs, mais ils sont considérés différemment.L'accent n'est pas mis sur les bogues eux-mêmes, mais sur la manière dont ils sont collectés, hiérarchisés et résolus.Les bogues eux-mêmes apparaissent comme le résultat d'une dette technique (comme dans l'exemple précédent), mais n'apparaissent jamais eux-mêmes comme un facteur de dette technique.
Ceci étant dit, je suis toujours enclin à répondre que les bugs — n'importe quels bugs — font partie de la dette technique.
Premier argument :
En lisant la citation de Jeff Atwood, la plupart des bogues seraient qualifiés de :
l'effort supplémentaire que nous devons faire dans le développement futur en raison du choix de conception rapide et sale
Dans les applications d'entreprise, presque chaque bogue provient soit d'un choix de conception rapide et sale, soit de mauvaises pratiques (serait-ce le manque de tests, l'utilisation de technologies que les développeurs ne connaissent pas assez, le manque de communication, le manque de compréhension du domaine,etc.) Cela signifie qu '"en refactorisant la conception rapide et sale en une meilleure conception" et en adaptant de meilleures pratiques, les entreprises pourraient résoudre la plupart de leurs bogues.
Deuxième argument :
Si l'on fait un parallèle entre la dette ordinaire d'une entreprise qu'il est important de prendre en compte lorsqu'une entreprise est vendue à une autre, et la dette technique, qu'il est tout aussi important de prendre en compte lorsqu'un projet est vendu à une autre entreprise ou donnéà une autre équipe, on voit facilement que les bugs font partie de la dette technique, puisque la nouvelle équipe :
Soit vous devez traiter ces bogues avant de créer de nouvelles fonctionnalités (point 5 du test de Joel : corrigez-vous les bogues avant d'écrire un nouveau code ?)
Ou garder les bugs, préservant/augmentant ainsi la dette technique.
Jeff Atwood dans son article Rembourser votre dette technique donne une assez belle réponse sur ce qu'est la dette technique :
la dette technique entraîne des paiements d'intérêts, qui se présentent sous la forme de l'effort supplémentaire que nous devons faire dans le développement futur en raison du choix de conception rapide et sale.Nous pouvons choisir de continuer à payer les intérêts, ou nous pouvons rembourser le principal en refactorisant la conception rapide et sale dans la meilleure conception.Même s'il en coûte de rembourser le principal, nous gagnons en réduisant les paiements d'intérêts à l'avenir.
À proprement parler, les bogues ne font pas partie de la dette technique, s'ils ne ralentissent pas le développement ultérieur du logiciel (changer des choses, ajouter de nouvelles fonctionnalités, etc.).Ce sont des défauts logiciels.
Cependant, lorsqu'il est trop coûteux de corriger un bogue, ou que cela vous oblige à le contourner (et à introduire encore plus de dette technique), cela devient alors une partie de la dette technique.
Un bug n'est pas une dette technique.La dette technique lésine sur la qualité, pas sur son absence.Le logiciel ne doit pas être livré avec des bogues en premier lieu.Vous savez, tout ce logiciel de travail sur une documentation complète.
Les plus grands contrevenants de la dette technique sont les "corrections de bogues temporaires", vous savez celles que vous mettez pour réussir le test et faire accepter l'histoire Celles que vous vous êtes promis de refactoriser plus tard, mais que vous ne ferez jamais.Au fur et à mesure que ces correctifs temporaires, correctifs et autres éléments s'accumulent, le code devient inutilement encombré, difficile à mettre à jour et à tester et, en général, c'est un cauchemar, mais il fait toujours son travail.
Pour étayer cette opinion, je suis allé directement à la source, Ward Cunningham.À ce sujet, Ward a fait une bonne interview il y a quelque temps avec Capers Jones, ça vaut le détour.
Débat technique sur la dette, avec Ward Cunningham & Capers Jones
Un autre article qui vaut la peine d'être lu est celui de Martin Fowler
Martin Fowler sur la dette technique
Dans l'article de Martin, veuillez trouver le lien vers la mention originale de la dette technique par Ward Cunningham, de OOPSLA92 :
Le système de gestion de portefeuille WyCash
Une citation de l'article ci-dessus:
Bien qu'un code immature puisse fonctionner correctement et être tout à fait acceptable pour le client , des quantités excessives rendront un programme impossible à maîtriser, conduisant à une spécialisation extrême des programmeurs et finalement à un produit inflexible.Expédier le premier code horaire, c'est comme s'endetter.
En fin de compte, la dette technique en est peut-être venue à inclure des bogues pour certaines personnes, et je suppose que c'est bien.Je ne pense tout simplement pas que c'était l'intention initiale.
À mon avis, peu importe que vous disiez que les bogues font partie de la dette technique ... ou non.
Le fait est que les bogues existants représentent un travail supplémentaire qui devra peut -être être effectué à l'avenir, soit pour les corriger, soit pour les contourner.
La dette technique (comme l'étiquette est généralement utilisée) représente également un travail supplémentaire qui devra peut -être être effectué à l'avenir... d'une manière ou d'une autre.
Donc, que vous disiez que les bugs connus (ou inconnus) sont une dette technique... ou pas... c'est vraiment une question de définitions.Et puisqu'il n'y a pas de définition faisant autorité 1 de la "dette technique", toute la discussion est en quelque sorte inutile.
Comme l'a écrit Lewis Carroll :
« Quand j'emploie un mot, dit Humpty Dumpty d'un ton plutôt méprisant, cela veut dire exactement ce que je veux qu'il signifie — ni plus ni moins..
C'est en fait ainsi que fonctionne le langage naturel.Les mots veulent dire ce que les gens pensent qu'ils veulent dire.Les définitions des dictionnaires et ainsi de suite documentent simplement la manière dont les mots sont utilisés, et elles ne constituent pas nécessairement une documentation précise.Si votre Scrum Master veut qualifier les bugs connus de dette technique, qui peut dire qu'il a « tort » ?
1 - Citer des gens comme Ward Cummingham et Caper Jones n'aide pas non plus.Au mieux, cela nous dit ce qu'ils veulent dire (ou voulaient dire) quand ils utilisent (utilisent) la phrase.Ils ne "possèdent" pas la phrase.Bien qu'ils soient sans aucun doute des autorités sur ces questions, ce n'est encore que leur opinion.
Strictement parlant, la réponse à votre question est non.
La dette technique peut (et va probablement) conduire à des bogues, mais conclure que tout bogue est le résultat d'une dette technique met une interprétation entre deux faits : il y a un bogue et il y a une dette technique (en supposant que cela puisse être conclu comme un fait).
Si votre Scrum Master énonce "en théorie" que les bugs sont le résultat d'une dette technique, il prend des raccourcis.S'il dit cela à propos de bogues spécifiques qui réapparaissent sans cesse, il a peut-être raison - nous ne pouvons pas voir la qualité du code d'ici ;-)
Il peut également avoir une plainte continue au sujet des personnes qui ne l'écoutent pas au sujet de la dette technique, et donc étiqueter chaque bogue comme une dette technique, mais maintenant je spécule.
