{"id":251754,"date":"2023-03-02T06:48:00","date_gmt":"2023-03-02T03:48:00","guid":{"rendered":"https:\/\/inform.click\/comment-evaluer-gerer-et-eviter-les-dettes-techniques\/"},"modified":"2023-03-02T07:14:00","modified_gmt":"2023-03-02T04:14:00","slug":"comment-evaluer-gerer-et-eviter-les-dettes-techniques","status":"publish","type":"post","link":"https:\/\/inform.click\/fr\/comment-evaluer-gerer-et-eviter-les-dettes-techniques\/","title":{"rendered":"Comment \u00e9valuer, g\u00e9rer et \u00e9viter les dettes techniques"},"content":{"rendered":"

\n Si la dette technique ressemble \u00e0 quelque chose tir\u00e9 d’un manuel sur la finance, c’est parce que le terme est li\u00e9 \u00e0 la finance. Cependant, au sens propre, la dette technique est li\u00e9e \u00e0 la programmation. C’est l’id\u00e9e que lors du d\u00e9veloppement d’un projet logiciel, certaines \u00e9tapes n\u00e9cessaires sont saut\u00e9es, ou simplement abandonn\u00e9es dans le but de respecter un d\u00e9lai.\n<\/p>\n

\n Dans le but de d\u00e9velopper l’application ou le logiciel parfait, les d\u00e9veloppeurs sont souvent \u00e0 court de temps – tout comme n’importe quelle personne au hasard effectuant une t\u00e2che arbitraire de toute fa\u00e7on. Ainsi, il est g\u00e9n\u00e9ralement logique d’avoir une sorte de compromis entre la livraison d’un produit parfait avec un code parfait et la maximisation du temps.\n<\/p>\n

\n La question est alors: y a-t-il une limite \u00e0 ces arbitrages? Y a-t-il des pr\u00e9judices inh\u00e9rents qui pourraient r\u00e9sulter de ce compromis? Enfin, le d\u00e9veloppeur est-il vraiment mieux loti sur le long terme? Dans cet article sur les dettes techniques, je vais tenter de r\u00e9pondre \u00e0 toutes ces questions.\n<\/p>\n

\n Qu’est-ce que la dette technique ?
\n<\/h5>\n

\n Pour d\u00e9finir la dette technique, nous devrons nous r\u00e9f\u00e9rer \u00e0 l’homme cr\u00e9dit\u00e9 d’avoir g\u00e9n\u00e9r\u00e9 le terme en premier lieu: Ward Cunningham. Selon Cunningham, la dette technique fait r\u00e9f\u00e9rence au travail de d\u00e9veloppement suppl\u00e9mentaire qui doit \u00eatre consacr\u00e9 \u00e0 la programmation d’un code pour compenser le d\u00e9ficit r\u00e9sultant de sa programmation dans un court laps de temps.\n<\/p>\n

\n Pour le rendre plus graphique, imaginez que vous \u00eates charg\u00e9 de nettoyer une pi\u00e8ce en d\u00e9sordre et que vous \u00eates en retard pour un cours. Afin de vous assurer que vous suivez les instructions et que vous \u00eates \u00e0 l’heure pour votre cours, vous effectuez un nettoyage rapide en balayant la plupart des d\u00e9bris sous le canap\u00e9. Les retomb\u00e9es de cela sont que vous devrez \u00e9ventuellement prendre le temps de trier le d\u00e9sordre. Pour le d\u00e9veloppement de logiciels, lorsque vous ignorez les \u00e9tapes n\u00e9cessaires et suivez un itin\u00e9raire plus facile, avec des codes \u00ab\u00a0pas si propres\u00a0\u00bb, il deviendra plus difficile de nettoyer le code plus tard dans le futur. Il existe plusieurs phases rencontr\u00e9es dans les dominos du projet logiciel, et plus vous ignorez un probl\u00e8me existant, plus il faut de temps pour le r\u00e9soudre.\n<\/p>\n

\n Types de dettes techniques\n<\/p>\n

\n Les dettes techniques sont de diff\u00e9rents types, notamment :\n<\/p>\n

\n Dettes techniques pr\u00e9vues
\n<\/h5>\n

\n Cela se produit dans des situations o\u00f9 les organisations d\u00e9cident d\u00e9lib\u00e9r\u00e9ment de s’endetter techniquement. Ceci, comme nous l’avons vu pr\u00e9c\u00e9demment, consiste g\u00e9n\u00e9ralement \u00e0 respecter les d\u00e9lais fix\u00e9s et \u00e0 atteindre un objectif sp\u00e9cifique. Lorsqu’elle s’engage dans des dettes techniques planifi\u00e9es, l’organisation doit savoir clairement ce qu’elle est pr\u00eate \u00e0 abandonner et ce qu’elle ne peut pas. Vous devez tenir des registres pr\u00e9cis, en gardant \u00e0 l’esprit que vous devrez \u00e9ventuellement revenir et corriger les erreurs que vous avez ignor\u00e9es au d\u00e9but.\n<\/p>\n

\n Dettes techniques non intentionnelles
\n<\/h5>\n

\n Ce type de dette technique est \u00e0 l’oppos\u00e9 du premier. Elle survient lorsqu’une organisation ne pr\u00e9voit pas ou ne planifie pas de dette technique. La raison en est g\u00e9n\u00e9ralement une rupture de communication entre les diff\u00e9rentes unit\u00e9s de l’organisation ou de mauvaises pratiques de travail entre les unit\u00e9s.\n<\/p>\n

\n Dettes techniques in\u00e9vitables
\n<\/h5>\n

\n C’est le genre de dette technique qu’aucune action de l’organisation n’aurait pu emp\u00eacher. Par exemple, avec les changements rapides de la technologie, il est logique que certains codes \u00e9crits dans le pass\u00e9 ne respectent pas les normes actuelles projet\u00e9es.\n<\/p>\n

\n De plus, ce type de dette technique peut survenir lorsque des modifications sont demand\u00e9es alors que le code est d\u00e9j\u00e0 en cours d’\u00e9criture. Si \u00e0 mi-chemin de la conception du logiciel, certains changements sont introduits, cela pourrait perturber la dynamique, rendant l’ancien code obsol\u00e8te ou inutile.\n<\/p>\n

\n Causes de la dette technique
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Certaines des raisons de la dette technique ont \u00e9t\u00e9 discut\u00e9es ci-dessus, mais je vais simplement les s\u00e9lectionner les unes apr\u00e8s les autres pour les rendre plus claires.\n<\/p>\n

\n H\u00e2te
\n<\/h5>\n

\n La cause la plus fr\u00e9quente de la dette technique est la h\u00e2te. Les d\u00e9veloppeurs ont souvent des d\u00e9lais stricts, dont certains incluent des d\u00e9lais pour le lancement de certains logiciels. Il est souvent compr\u00e9hensible (et attendu) dans ce genre de situations que le d\u00e9veloppeur puisse contracter des dettes techniques en cours de route. Ce type de dette technique est souvent intentionnel et peut entra\u00eener des probl\u00e8mes pouvant aller de la pr\u00e9sence de bogues dans le code \u00e0 l’apparition de codes spaghetti.\n<\/p>\n

\n Oubli\/Erreur
\n<\/h5>\n

\n Parfois, les programmeurs \u00e9crivent simplement de mauvais codes, ce qui finit par entra\u00eener des dettes techniques. Que le mauvais code existe ou non \u00e0 la suite d’une erreur du codeur, le fait est que les erreurs entra\u00eenent des dettes techniques, et parce qu’elles ne sont pas \u00e9volutives, elles devront \u00e9ventuellement \u00eatre corrig\u00e9es.\n<\/p>\n

\n Manque de conscience des effets
\n<\/h5>\n

\n Parfois, des dettes techniques surviennent parce que le codeur ne r\u00e9alise pas ou ne reconna\u00eet pas \u00e0 quel point les dettes techniques sont nuisibles \u00e0 long terme. Cela pourrait provenir d’une ignorance l\u00e9gitime des effets n\u00e9fastes de prendre des raccourcis lors de la programmation, ou il pourrait s’agir d’un m\u00e9pris volontaire des cons\u00e9quences.\n<\/p>\n

\n Intention
\n<\/h5>\n

\n Les dettes techniques peuvent survenir intentionnellement par les actions d\u00e9lib\u00e9r\u00e9es du codeur ou de l’organisation.\n<\/p>\n

\n Manque de modularit\u00e9
\n<\/h5>\n

\n Cela se produit principalement parce qu’un code peut servir une logique m\u00e9tier diff\u00e9rente en m\u00eame temps. Ce genre de situation rend la manipulation des logiciels beaucoup plus difficile. Avec chaque code qu’un d\u00e9veloppeur \u00e9crit, plus il y a de chances qu’il rencontre des probl\u00e8mes de modularit\u00e9.\n<\/p>\n

\n \u00c9valuation de la dette technique
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Les dettes techniques ne doivent jamais \u00eatre calcul\u00e9es manuellement car cela serait assez ardu. Cela signifierait devoir saisir manuellement le code pour d\u00e9terminer les probl\u00e8mes actuels et les \u00e9ventuels probl\u00e8mes futurs. Outre la perte de temps du processus manuel, il est possible que les codes aient chang\u00e9 de forme \u00e0 la fin du processus manuel.\n<\/p>\n

\n Une fa\u00e7on de proc\u00e9der \u00e0 l’\u00e9valuation consiste \u00e0 effectuer une analyse statique \u00e0 l’aide de certains outils qui la prennent en charge. Certains des outils qui peuvent \u00eatre utilis\u00e9s incluent Coverity, SonarQube, Check Style et Closure Compiler.\n<\/p>\n

\n G\u00e9n\u00e9ralement, il existe deux mani\u00e8res de calculer les dettes techniques. Dans la premi\u00e8re approche, il pourrait \u00eatre obtenu en calculant le ratio de la dette technique suivant le code ratio. Ici, l’estimation initiale ou le temps global n\u00e9cessaire pour d\u00e9velopper l’application serait utilis\u00e9 pour d\u00e9terminer le temps n\u00e9cessaire pour r\u00e9gler la dette technique.\n<\/p>\n

\n Dans la deuxi\u00e8me approche, vous pouvez directement utiliser les estimations fournies par les diff\u00e9rents outils tels que SonarQube. Celui-ci sera combin\u00e9 avec les listes des dettes techniques ainsi que leurs codes de r\u00e9f\u00e9rence. \u00c0 partir des outils, vous pouvez obtenir une estimation pr\u00e9cise du temps n\u00e9cessaire pour le r\u00e9parer.\n<\/p>\n

\n L’\u00e9valuation de la dette technique vous donnera une id\u00e9e du nombre de jours qu’il faudra pour r\u00e9gler la dette technique. Plus il y a de dettes, plus il vous faudra de temps pour les r\u00e9parer.\n<\/p>\n

\n R\u00e9soudre les dettes techniques
\n<\/h3>\n

\n Que faire si des dettes techniques se sont produites et que vous ne savez pas quoi faire? Vous pouvez prendre certaines mesures pour g\u00e9rer les dettes techniques.\n<\/p>\n

\n Tout d’abord, vous devez reconna\u00eetre que les dettes techniques existent et en informer votre \u00e9quipe. En communiquant, vous devez \u00eatre clair sur ce qui s’est pass\u00e9 et sur ce qui doit \u00eatre fait pour y rem\u00e9dier. Vous devez vous assurer de communiquer clairement la n\u00e9cessit\u00e9 de prendre en charge la dette technique le plus t\u00f4t possible.\n<\/p>\n

\n Apr\u00e8s avoir inform\u00e9 votre \u00e9quipe des dettes techniques, vous pouvez adopter trois approches. Dans la premi\u00e8re approche, vous pourriez d\u00e9cider de continuer avec le syst\u00e8me tel qu’il est. Dans ce sc\u00e9nario, l’application sera utilis\u00e9e telle quelle.\n<\/p>\n

\n Alternativement, vous pouvez d\u00e9cider de refactoriser l’application. La refactorisation est effectu\u00e9e dans le but de r\u00e9duire la complexit\u00e9 de l’application ainsi que de nettoyer la structure de l’application. Avec le refactoring, le comportement du logiciel ne sera pas modifi\u00e9 ; la seule partie affect\u00e9e sera la structure interne.\n<\/p>\n

\n Enfin, si les deux options d\u00e9crites ci-dessus ne fonctionnent pas, vous devrez remplacer enti\u00e8rement le code. Un probl\u00e8me avec cela est que cela pourrait entra\u00eener de nouvelles dettes techniques, mais cela pourrait \u00eatre un meilleur compromis \u00e0 long terme.\n<\/p>\n

\n \u00c9viter les dettes techniques \u00e0 l’avenir
\n<\/h3>\n

\"\"<\/a><\/p>\n

\n Bien s\u00fbr, il va sans dire qu’il est nettement plus intelligent d’\u00e9viter les dettes techniques que d’essayer de les r\u00e9parer lorsqu’elles surviennent. Outre le fait qu’il vous fait gagner du temps et du stress, il garantit \u00e9galement que les cons\u00e9quences r\u00e9siduelles r\u00e9sultant des dettes techniques d\u00e8s le d\u00e9but sont absentes.\n<\/p>\n

\n On pourrait faire valoir que les dettes techniques, en elles-m\u00eames, ne sont pas mauvaises. Ils sont g\u00e9n\u00e9ralement probl\u00e9matiques car ce sont des dettes qui doivent \u00eatre rembours\u00e9es, et les humains ne sont pas l’esp\u00e8ce la plus responsable sur terre. Choisir syst\u00e9matiquement une option plus faible affaiblira g\u00e9n\u00e9ralement la force de votre logiciel et rendra plus difficile l’am\u00e9lioration ult\u00e9rieure des fonctionnalit\u00e9s. Dans l’ensemble, \u00e9viter les dettes techniques est le meilleur pari pour quiconque.\n<\/p>\n

\n Alors, comment \u00e9viter les dettes techniques :\n<\/p>\n

\n Cr\u00e9er un backlog de projet\n<\/p>\n

\n L’id\u00e9e ici est de tenir tout le monde au courant du processus et de les mettre au courant des exigences de la t\u00e2che \u00e0 accomplir. La cr\u00e9ation d’un backlog permet \u00e0 chacun de voir les t\u00e2ches non r\u00e9alis\u00e9es et les chemins \u00e0 suivre pour les r\u00e9aliser.\n<\/p>\n

\n Privil\u00e9giez la qualit\u00e9 \u00e0 la rapidit\u00e9\n<\/p>\n

\n Si vous \u00eates vous-m\u00eame programmeur, vous devez apprendre \u00e0 donner la priorit\u00e9 \u00e0 un travail de qualit\u00e9 plut\u00f4t qu’\u00e0 beaucoup de travail. Assurez-vous que vos codes sont propres et que vos applications ou autres logiciels sont d\u00e9velopp\u00e9s \u00e0 la perfection. Comprenez que la tentation de prendre des raccourcis n’en vaudra pas la peine car \u00e0 terme, vous devrez toujours effectuer les t\u00e2ches que vous avez largu\u00e9es.\n<\/p>\n

\n Si vous dirigez une \u00e9quipe, vous devez communiquer ces m\u00eames valeurs aux membres de l’\u00e9quipe. Les membres doivent apprendre \u00e0 cr\u00e9er des solutions ax\u00e9es sur les r\u00e9sultats et \u00e0 \u00e9viter les raccourcis.\n<\/p>\n

\n Sensibiliser\n<\/p>\n

\n G\u00e9n\u00e9ralement, une connaissance approfondie de ce qu’est la dette technique et de la mani\u00e8re de l’\u00e9viter peut \u00eatre utile pour \u00e9viter qu’elle ne survienne en premier lieu. Lorsque vous armez vos d\u00e9veloppeurs des connaissances n\u00e9cessaires, ils \u00e9viteront mieux les pi\u00e8ges que posent les dettes techniques.\n<\/p>\n

\n Introduire les bonnes pratiques de codage\n<\/p>\n

\n Certaines pratiques de codage rendent plus probable qu’improbable que vous tombiez dans une dette technique. Ainsi, il serait bon d’\u00e9viter le couplage \u00e9troit, d’utiliser l’abstraction et la refactorisation.\n<\/p>\n

\n Introduire une technologie mise \u00e0 jour\n<\/p>\n

\n Des mises \u00e0 jour r\u00e9guli\u00e8res de la technologie peuvent \u00eatre un excellent moyen de pr\u00e9venir les dettes techniques. Lors de la mise \u00e0 jour, vous devez vous assurer que ce qui est utilis\u00e9 est le dernier framework, bases de donn\u00e9es et logiciels d’application.\n<\/p>\n

\n Conclusion
\n<\/h5>\n

\n Les dettes techniques, dans la grande majorit\u00e9 des cas, sont in\u00e9vitables tant que vous continuez \u00e0 d\u00e9velopper des programmes et \u00e0 \u00e9crire des codes. Cependant, les chances de leur apparition peuvent \u00eatre consid\u00e9rablement r\u00e9duites lorsque les \u00e9tapes \u00e9num\u00e9r\u00e9es ci-dessus sont suivies. Aussi, dans l’\u00e9ventualit\u00e9 de dettes techniques, tout espoir n’est pas perdu. Restez calme, soyez confiant, agissez en cons\u00e9quence.\n<\/p>\n<\/p>\n

\n Source d’enregistrement: instantshift.com<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Si la dette technique ressemble \u00e0 quelque chose tir\u00e9 d’un manuel sur la finance, c’est parce que le terme est li\u00e9 \u00e0 la finance. Cependant, au sens propre, la dette technique est li\u00e9e \u00e0 la programmation. C’est l’id\u00e9e que lors du d\u00e9veloppement d’un projet logiciel, certaines \u00e9tapes n\u00e9cessaires sont saut\u00e9es, ou simplement abandonn\u00e9es dans le but de respecter un d\u00e9lai. Dans le but de d\u00e9velopper l’application ou le logiciel parfait, les d\u00e9veloppeurs sont souvent \u00e0 court de temps – tout comme n’importe quelle personne au hasard effectuant une t\u00e2che arbitraire de toute fa\u00e7on. Ainsi, il est g\u00e9n\u00e9ralement logique d’avoir une sorte de\u2026<\/p>\n","protected":false},"author":1,"featured_media":209172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[210,262,93,54],"tags":[],"class_list":["post-251754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-codage","category-psychologie-2","category-referencement-et-marketing","category-web-et-wordpress"],"_links":{"self":[{"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/posts\/251754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/comments?post=251754"}],"version-history":[{"count":0,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/posts\/251754\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/media\/209172"}],"wp:attachment":[{"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/media?parent=251754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/categories?post=251754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inform.click\/fr\/wp-json\/wp\/v2\/tags?post=251754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}