Mauvais karma en programmation. Qu'est-ce que la dette technique et comment y remédier

Dette technique. La plupart des programmeurs travaillant activement dans leur spécialité doivent composer avec ce terme. Pour beaucoup, sa mention peut même provoquer des maux de tête, ainsi qu'un inconfort dans d'autres parties du corps qui apparaît chaque fois que l'on fait face à une dette technique en travaillant sur un projet. C’est pourquoi nous parlerons aujourd’hui de la dette technique (TD) : qu’est-ce que c’est, comment elle apparaît, quels types de dette technique existe et comment la gérer efficacement.

Qu’est-ce que la dette technique ?

Cependant, commençons par comprendre la terminologie. La dette technique est une métaphore du génie logiciel pour les problèmes accumulés dans le code ou l'architecture logiciel en raison de la négligence de la qualité du développement logiciel et entraînant des coûts de main-d'œuvre supplémentaires à l'avenir. C’est la définition de la dette technique donnée par Wikipédia. Pour le dire simplement, la dette technique est le résultat de l'application de solutions de développement simplifiées et à court terme, qui conduisent ensuite à des coûts d'argent et de temps toujours croissants (à moins, bien sûr, que la dette ne soit «remboursée») pour un raffinement ultérieur. réécrire le code ou maintenir le produit dans sa forme existante. Dans le monde des programmeurs ordinaires, la dette technique est l'un des types de karma négatif, un démotivateur et une source de tristesse qui vient en guise de châtiment pour un mauvais code, l'utilisation de béquilles et de solutions « temporaires » (mais en fait pas très) qui contribuer à résoudre les problèmes à court terme et à accélérer le développement « à crédit », c’est-à-dire au prix d’un enchevêtrement croissant de problèmes à l’avenir. Dans l'industrie informatique, la dette technique est un problème assez grave. Selon une étude récente , les entreprises du monde entier dépensent chaque année plus de 85 milliards de dollars uniquement pour corriger les mauvais codes. Au total, environ 300 milliards de dollars par an sont dépensés pour des projets liés à la prise en charge de systèmes obsolètes et de « mauvais » logiciels. Ce sont des chiffres significatifs. Les chercheurs estiment que si les efforts de tous les développeurs qui travaillent avec la dette technique et ses conséquences étaient recentrés sur un « bon » développement, cela ajouterait environ 3 000 milliards de dollars au PIB mondial au cours de la décennie en cours.

Raisons de l'apparition

Il faut bien comprendre que l'endettement technique n'est pas toujours une mauvaise chose, tout comme s'endetter financièrement peut être positif si, par exemple, on contracte un emprunt pour développer une entreprise (ou lancer une startup ). Dans le cas de TD, cela est acceptable pour les entreprises en croissance rapide qui doivent lancer de nouveaux produits ou services rapidement et souvent afin d'évaluer leur succès et d'étudier les besoins du marché, ou de conquérir rapidement de nouveaux créneaux, par exemple. Mais comme pour les dettes financières, il faut être prudent avec les dettes techniques et savoir les gérer, sinon de sérieux problèmes peuvent survenir. Plus la dette technique accumulée lors du développement d'un produit logiciel est importante, plus elle peut affecter l'entreprise, en ralentissant la sortie des nouvelles versions, en abaissant le moral des codeurs ordinaires qui sont responsables du « maintien » de cette dette et en augmentant les coûts. , ce qui peut même finir par détruire l'entreprise. Les raisons de l'apparition d'une dette technique, en plus du noble désir de terminer le produit le plus rapidement possible ou de plaire aux utilisateurs avec une nouvelle version, sont souvent une mauvaise gestion du produit, des délais irréalistes ou des ressources limitées, et bien sûr, la paresse du codeur. , couplé à de faibles qualifications et à un manque de compréhension des principes clés du développement, contribue également souvent à l'augmentation de la dette. Il arrive souvent que les développeurs eux-mêmes soient bien conscients de la présence et de la croissance constante de la dette technique, mais n'ont pas suffisamment de pouvoir pour la modifier, ou ne peuvent pas transmettre d'informations à la direction sur l'existence d'un tel problème et l'importance de le résoudre.

Classification

Comme mentionné ci-dessus, la dette technique se présente sous de nombreuses formes différentes, et comme la définition elle-même n’est qu’une métaphore, les différents types de dette technique peuvent être classés de différentes manières. En particulier, Dag Liodden, co-fondateur et CTO de Tapad, considéré comme l'un des experts mondiaux en matière de dette technique, a proposé, lors d'un discours prononcé lors du sommet annuel du CTO, de diviser la dette technique en trois types principaux.

1. Dette technique intentionnelle.

   Cela apparaît dans les cas où les développeurs ne choisissent délibérément pas la meilleure solution, car elle est plus facile et plus rapide à mettre en œuvre, ce qui, à son tour, contribuera à lancer rapidement un nouveau produit sur le marché.

   « Parfois, nous contractons délibérément une dette technique pour réduire le temps de développement. Si vous décidez de suivre cette voie, considérez non seulement le temps que vous gagnerez pendant le développement, mais également le temps que vous devrez consacrer plus tard pour « rembourser » cette dette. Assurez-vous également que les parties prenantes [la haute direction de l'entreprise] sont conscientes qu'une telle décision ralentira inévitablement le lancement d'autres fonctions à l'avenir », a déclaré Dag Ljodden.

   Une approche pour résoudre ce type de dette technique

   L'expert conseille de documenter soigneusement ces cas afin d'y revenir et de les corriger avant que cette dette technique ne soit perdue, devenant partie intégrante de la structure du projet.

2. Dette technique accidentelle ou résultant d’une architecture de projet obsolète.

   De plus, la dette technique apparaît souvent au fil du temps, en raison d'erreurs et de lacunes au stade de la création de l'architecture du projet. À mesure que les systèmes évoluent et que les exigences logicielles changent, les erreurs de conception deviennent plus apparentes et l'ajout de nouvelles fonctionnalités nécessite plus de temps et d'efforts. La qualité de l'architecture initiale du projet joue ici un rôle important : elle doit être à la fois simple et fonctionnelle, il sera alors plus facile de s'adapter aux changements.

   Une approche pour résoudre ce type de dette technique

   Pour éviter que ce type de dette technique ne s'accumule et ne dépasse des niveaux critiques, Dag Llodden recommande de refactoriser régulièrement - environ une fois tous les deux ans, pendant les périodes où le système est dans un état stable. Les chefs d'équipe et les chefs de produit doivent consacrer du temps pour « rembourser » ce type de dette technique qui résulte de l'architecture et des exigences fréquemment changeantes du projet.

3. Dette technique qui apparaît avec le temps.

   L’expert qualifie cette dette technique de « pourrissante depuis longtemps ». Il s'accumule au fil du temps à mesure qu'un composant ou un système devient progressivement plus complexe en raison de nombreux changements constamment ajoutés. Ce problème est souvent exacerbé si différentes personnes travaillent sur le système à différentes étapes et ne comprennent pas pleinement l'architecture d'origine.

   Une approche pour résoudre ce type de dette technique

   C'est le seul des trois types de dette technique que vous devriez essayer d'éviter de manière continue grâce à un refactoring régulier, explique l'expert. Idéalement, une équipe de développement devrait prendre le temps de bien comprendre l’architecture du système sur lequel elle travaille, même s’il a été créé à l’origine par d’autres personnes. Comprendre le système vous permettra d'améliorer et de corriger progressivement le mauvais code sans amener le projet au stade de la « pourriture ».

Solutions techniques de gestion de la dette

Il existe de nombreuses options pour gérer efficacement la dette technique, mais tous les experts conviennent que cela doit être fait, car la dette technique fait partie intégrante de presque tout développement, et les entreprises qui l'ignorent sont invariablement confrontées à des problèmes à des stades ultérieurs. Voici quelques solutions et approches efficaces pour gérer la dette technique d’une équipe de développement.

1. Allouez un pourcentage fixe de votre temps de travail au travail sur la dette technique.

   Le problème avec la dette technique, c’est qu’on n’a jamais le temps de travailler à son élimination (car il y a toujours des tâches plus prioritaires) à moins que vous ne le fassiez délibérément. Par conséquent, une bonne solution serait d'allouer un certain pourcentage fixe du temps de travail à ces fins - environ 20 à 25 %.

   Cela peut se faire de différentes façons.

2. Travailler sur la dette technique 1 jour par semaine

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

Enfin, je voudrais souligner encore une fois qu'il est impossible de se passer de la dette technique dans le développement logiciel, car elle fait partie intégrante du développement en tant que tel. Cependant, malgré sa nature technique, le TD reste un problème causé par le facteur humain dans le développement. Et même si vous ne pourrez pas vous en passer complètement, le montant de la dette technique peut être réduit autant que possible si vous écrivez du code « propre » et abordez le processus de développement de la manière la plus responsable et professionnelle possible. C'est ce que nous souhaitons à tous !