Qu'est-ce que la dette technique et pouvez-vous l'éviter ?

Si vous êtes dans le développement de logiciels, vous allez devoir faire face à une dette technique à un moment donné. Alors pour répondre à la question du titre… non, vous ne pouvez pas l'éviter. Cependant, il existe des mesures que vous pouvez prendre pour minimiser ses effets et vous assurer qu'il ne devient pas incontrôlable. Au moins trop mal.

Qu'est-ce que la dette technique ?

La dette technologique, comme on l'appelle parfois, est essentiellement le coût que vous encourez au fil du temps pour avoir un code imparfait. Les modifications et les mises à jour du code source ont un coût, tout comme l'ajout d'un nouveau membre à l'équipe de développement, l'ajout d'une nouvelle fonctionnalité ou la correction de bogues et de correctifs.

Au fur et à mesure que votre projet s'agrandit, que la base de code s'étend et que de plus en plus de personnes travaillent sur ce code, leurs voix et leurs styles se heurteront ici et là. Peut-être que vous avez une date limite et qu'une solution moins qu'idéale est corrigée dans le code source pour terminer à temps. Peut-être que vous ajoutez un composant open source que vous ne comprenez pas parfaitement pour gérer une fonctionnalité au lieu de la coder vous-même. Ou vous pouvez basculer les bibliothèques entre les versions (de Backbone à React, par exemple), mais devez toujours prendre en charge les personnes utilisant la base de code héritée pour leurs projets.

Absolument aucune de ces choses n'est mauvaise . Pas tout seul. Peut-être pas du tout. Mais une fois additionnées, la dette technique qu'elles contractent devra être remboursée à un moment donné dans le futur.

À un moment donné, ce composant open source devra peut-être être remplacé (ou fork). Cela coûtera du temps et de l'argent. Dans un avenir lointain, vous devrez supprimer tout le code Backbone de votre projet et cesser de prendre en charge les utilisateurs hérités. Encore une fois, du temps et de l'argent. Ce patch que vous avez fait pour respecter une échéance ? Eh bien, cela finira par se défaire et nécessitera une solution plus permanente. Du temps et de l'argent. Et vous aurez de nouveaux membres de votre équipe qui reprennent l'ancien code pour faire tout cela, ayant besoin de comprendre le code et la logique des développeurs précédents. Temps. De l'argent.

Vous l'obtenez.

Alors que la dette technique est un terme abstrait, souvent métaphorique, le coût de la dette technologique est bien réel. Le rembourser a une valeur monétaire et vous pouvez suivre les intérêts que vous payez en heures de travail et en bulletins de paie. Vous pouvez le voir dans la ligne de fond de tout développement de logiciel.

Pouvez-vous éviter la dette technologique ?

Comme je l'ai déjà dit… pas vraiment, non. Vous allez accumuler une dette technique dans chaque projet que vous écrivez si jamais vous revenez au code après sa sortie. Cependant, si vous décomposez les types de dette technique, vous pouvez la minimiser et même la comptabiliser dans vos projets. Si vous considérez la dette à l'avance, ce n'est pas différent de contracter un prêt automobile ou une hypothèque. Vous examinez le coût, les intérêts et les avantages, puis vous décidez si vous pouvez/voulez le payer.

Jetons un coup d'œil à certains des exemples dont nous avons discuté ci-dessus et voyons s'il existe un moyen d'éviter, de minimiser ou d'absorber le coût.

Considérer la dette technique intentionnelle

Lorsque nous parlons de dette technique intentionnelle, nous voulons dire que votre équipe a pris des décisions qui, vous le savez, ne correspondent pas aux meilleures pratiques pour le langage ou le type de projet sur lequel vous travaillez. Nous avons mentionné plus tôt que vous pourriez avoir une date limite à respecter. Et peut-être que cette date limite est dure et rapide. Peut-être qu'il y a 0% de chance qu'il soit modifié ou déplacé.

C'est à ce moment-là qu'il faut envisager de contracter un emprunt et de s'endetter techniquement.

Vous avez vraiment trois options ici :

• Sortez des logiciels inachevés et buggés, mais vous ne faites aucune concession sur la clarté et la logique du code
• Tirez des fonctionnalités que vous ne parvenez pas à perfectionner, mais libérez ce que vous avez qui est aussi bien écrit que possible
• Prenez des décisions de développement qui produisent un code « assez bon » pour que tout fonctionne, mais devront probablement être abordées à nouveau plus tard

La troisième option ici est souvent celle que les gens choisissent. C'est entrer dans la dette technique. Et il n'y a rien de mal à cela. Parce que vous avez pris la décision de le faire .

Rembourser le prêt d'une dette intentionnelle

Assurez-vous de documenter les décisions derrière le choix d'emprunter cette voie dans votre code. Notez ce que vous avez fait par rapport à la solution idéale. Et assurez-vous d'inclure au moins une sorte de commentaire dans le code source pour indiquer où cette solution de prise de dette a été mise en œuvre (et si vous le savez, les systèmes affectés dans d'autres domaines du projet). Si vous ne franchissez pas cette étape, l'ajout au projet (même dans les corrections de bogues et les correctifs, sans parler de nouvelles fonctionnalités ou d'une base de code étendue) peut être horriblement retardé en trouvant une solution de patchwork lorsque vous en attendez une complète.

Encore une fois, cette solution de patchwork pourrait parfaitement convenir et ne jamais vous poser de vrais problèmes. Mais la dette technique est toujours là et doit être comptabilisée.

Prise en compte de la dette technique du code hérité

Un autre type courant de dette technique est celui que WordPress accumule beaucoup en ce moment. WordPress peut fonctionner sur PHP 5.x. La dernière mise à jour, cependant, indiquera aux utilisateurs qu'il doit au moins être en PHP 5.6. D'ici fin 2019, le WP Core nécessitera PHP 7.x. Cependant, en augmentant les exigences, beaucoup d'anciens codes doivent être mis à jour. Parce qu'il y a toujours du code PHP 5.x dans les plugins, les thèmes et le Core lui-même.

Sans parler du nouvel éditeur de blocs. C'est écrit en JavaScript. Réagissez, précisément. Ce n'est rien près de PHP. En fait, une grande partie du noyau WordPress est en train d'être réécrite en JavaScript, petit à petit. Mais tout ce que JS doit compléter et s'entendre avec le PHP aussi. Adopter une nouvelle technologie est formidable, et adopter de nouvelles exigences de gestion des versions est nécessaire. Mais ce faisant, vous payez des intérêts sur la dette technique inévitable que vous encourez du fait que ce logiciel existe depuis un certain temps.

Rembourser la dette du code hérité

Celui-ci est un peu difficile parce qu'il n'y a pas une bonne façon de le faire. Vous pouvez prendre l'option nucléaire et faire une réécriture complète à partir de zéro dans le nouveau langage/framework/version (regardez ce que nous avons fait entre Divi 2 et Divi 3.0, en passant de Backbone.js à React). Cela ne résout toujours pas entièrement le problème de la dette, car vous avez toujours des gens qui utilisent l'ancienne bibliothèque. À un moment donné, vous devrez abandonner la prise en charge de la base de code héritée. Ce qui revient un peu à rembourser le prêt. Jusqu'à ce que vous deviez sortir le suivant.

Si ce n'est pas une option (ou la meilleure idée pour vous), vous pouvez vous assurer que vous ne comptez pas sur des fonctionnalités spécifiques à la langue ou à la version. Les développeurs frontaux doivent faire face à cela tout le temps, car certains navigateurs prennent en charge rapidement de nouvelles fonctionnalités, tandis que d'autres (Microsoft Edge/IE, toux toux) pourraient ne jamais l'adopter. Vous pouvez pérenniser vos projets en vous en tenant aux bases, ce qui, à son tour, apportera moins de modifications à apporter lors de la mise à niveau ou de la refactorisation qu'elles ne le seraient autrement.

Considérer plusieurs développeurs au fil du temps

Il s'agit d'une sorte de dette technologique que les grandes équipes ont tendance à accumuler au fil du temps pire que les petites équipes de développement. Même si les plus petits doivent aussi s'en soucier. Vous voyez, chaque ingénieur logiciel écrit le code différemment. Vous aurez très rarement deux développeurs qui résolvent le même problème avec exactement le même code. Ils peuvent remplir la même fonction et le résultat final peut être le même, mais le code sera écrit avec la voix de l'auteur (tout comme vous pouvez dire qui a écrit les messages ici, par exemple, comme Jason, Nathan, Donjete et J'ai tous des styles différents). Le code n'est pas différent.

En gardant cela à l'esprit, la logique peut parfois aussi avoir des voix différentes. Ce qu'un développeur pense est parfaitement clair, un autre développeur le regardera et n'aura aucune idée de pourquoi le code fait ce qu'il fait. Ce problème devient vraiment problématique lorsque l'auteur original n'est plus disponible pour consultation. La dette technique ainsi accumulée peut être catastrophique. Mais il existe des moyens de le gérer.

Rembourser la dette technique des anciens devs

Le moyen le plus simple est d'embaucher les meilleurs développeurs possibles et de ne jamais les laisser quitter votre entreprise. Déjà.

Étant donné que cela ne se produira pas environ 100 % du temps, le remboursement de cette dette peut être atténué un peu plus facilement que vous ne le pensez. Tout d'abord, assurez-vous de former votre équipe de développement à commenter leur code. Et de bien le commenter. Chaque fois qu'ils prennent une décision qui pourrait même être considérée comme ambiguë par quelqu'un d'autre, demandez-leur de noter pourquoi ils l'ont fait et comment la fonction fonctionne.

De plus, assurez-vous que chaque développeur de votre équipe respecte un guide de style ou un ensemble de normes. WordPress Core dispose d'un ensemble de normes de codage qui maintiendront les plugins, les thèmes et les contributions Core en ligne afin que toute autre personne venant plus tard n'ait aucun problème avec cela. Airbnb a un guide de style pour React qui a été adopté comme norme non officielle à l'échelle de l'industrie. Même les guides de style et les normes internes empêchent vos développeurs d'aller trop loin par eux-mêmes, car ces types de commits ne seront pas fusionnés à moins qu'ils ne soient à la hauteur.

Emballer

La dette technique est un problème bien réel. C'est aussi une ressource bien réelle si vous savez la gérer. En étant capable de décider quand vous contracterez une dette technologique et comment vous la rembourserez, votre développement peut se dérouler plus rapidement et plus facilement que possible. Et dans ces moments où assumer ce fardeau est inévitable, nous espérons vous avoir donné quelques idées de stratégies que vous pouvez mettre en œuvre pour le rendre moins impactant qu'il ne le serait autrement.

Comment gérez-vous la dette technique au sein de vos projets et équipes de développement ?

Article présenté en image par Andrey Suslov/ shutterstock.com