Avez-vous déjà essayé d'utiliser un sèche-cheveux pour dégivrer votre congélateur ? Non ? Vraiment ? Et pourquoi pas utiliser du ruban adhésif pour maintenir la porte de votre réfrigérateur fermée ? Si ces exemples vous semblent familiers, bienvenue dans le monde du « Gambiarra ». Pour les non-initiés, gambiarra est un terme brésilien qui décrit l'utilisation d'une chose d'une manière pour laquelle elle n'a pas été initialement conçue - une solution de rechange créative, parfois ingénieuse, mais certainement pas une solution à long terme.

Dans le monde de la technologie, les gambiarras consistent à ajouter des éléments secondaires au code existant au lieu de créer des fonctions et des méthodes indépendantes pour résoudre ces problèmes. Cela nous amène à ce que nous appelons en blague la « programmation orientée gambiarras » - "Gambiarra-Oriented Programming" (GOP), qui est un jeu de mots sur la « programmation orientée objet » - Object-Oriented Programming (OOP). En GOP, vous pouvez prendre un raccourci en forçant un morceau de code à résoudre un problème pour lequel il n'a pas été conçu ou en modifiant une fonctionnalité existante pour qu'elle remplisse une fonction non prévue à la base. La GOP est synonyme de solutions rapides et désordonnées où les fonctions et les méthodes commencent à faire des choses différentes de celles pour lesquelles elles ont été désignées à l'origine. Ces solutions improvisées peuvent permettre de faire le travail à court terme, mais elles contribuent à ce que nous appelons la dette technique.

La dette technique n'est pas comme une dette d'argent, mais plutôt comme l'encombrement que l'on accumule dans un garage. Elle commence modestement - un bug négligé par-ci, une fonctionnalité bâclée par là - puis, au fil du temps, elle s'accumule, rendant les développements futurs plus coûteux et plus fastidieux. Les « intérêts » sur cette dette se cumulent, chaque nouvelle fonctionnalité ou ajout au code doit fonctionner au-dessus de ces bidouillages et solutions de rechange, ce qui ralentit le progrès et rend la maintenance plus complexe. C'est l'équivalent de toujours remettre à plus tard la réparation de cette chaise instable ; elle finira par s'effondrer, et ce probablement pendant le repas de Noël.

Alors pourquoi se retrouve-t-on avec une dette technique si lourde ? Parfois, c'est à cause d’échéances serrées, où l'accent est mis sur la rapidité plutôt que sur la qualité. D'autres fois, c'est parce que la charge de travail immédiate ne laisse pas le temps de revenir sur ces corrections provisoires. Et souvent, c'est la tentative de mettre en œuvre une solution rapide en se disant « je reviendrai là-dessus plus tard » - même si ce « plus tard » ne semble jamais venir.

Cette accumulation de « dette » perturbe non seulement le développement, mais rend aussi la communication d'estimations précises aux parties prenantes pratiquement impossible. Ce qui semblait être la simple mise en œuvre d'une fonctionnalité peut maintenant devenir étonnamment plus complexe à mesure que la dette technique fait surface, ce qui perturbe considérablement l’échéancier. Au fil du temps, le coût de gestion de cette dette peut monter en flèche, rendant finalement la création de nouvelles fonctionnalités trop dispendieuse. C'est comme un « jeu de la taupe », où une solution rapide devient une fonctionnalité permanente et crée plus de problèmes qu'elle n'en résout.

Mais comment éviter la dette technique en premier lieu ? Deux pratiques clés peuvent vous aider : écrire du « clean code » et suivre un développement dirigé en fonction des tests (Test-Driven Development - TDD).

Écrire du clean « clean code » signifie que votre code doit rester simple, lisible et facile à maintenir. Chaque élément de code ne fait qu'une seule chose, et le fait bien. Il s'agit de faire les choses correctement dès le départ, même si cela demande un peu plus de temps. Un code propre évite toute complexité inutile, ce qui le rend plus facile à développer et moins susceptible d'accumuler une dette technique au fil du temps. C'est un peu comme si l'on gardait son espace de travail bien rangé : tout est à sa place et l'on peut trouver ce dont on a besoin sans avoir à fouiller dans des piles de désordre.

De son côté, le TDD est un processus de développement qui encourage l'écriture de tests avant d’écrire le code lui-même. En définissant d'abord les résultats souhaités, vous vous assurez que votre code répond aux exigences et qu'il sera plus facile de le remanier sans introduire de nouveaux problèmes. Le TDD encourage naturellement les développeurs à écrire un code propre et modulaire, puisque lorsqu'ils écrivent des tests préliminaires, ils sont obligés de garder leur code simple et ciblé. Ensemble, les pratiques de TDD et le « clean code » constituent un solide moyen de dissuasion contre la dette technique.

Mais que faire si vous avez déjà accumulé de la dette technique ? Il ne suffit pas d'en reconnaître l'existence, il faut en faire une priorité. Cela implique de prévoir du temps pour remanier le vieux code, mettre à jour les dépendances et réexaminer les solutions « temporaires ». Le coût de la négligence n'est pas seulement avec le code, mais aussi dans l'impact que cela a sur votre organisation et sur le moral de votre équipe. C'est comme désencombrer le garage : commencez par les petites choses faciles à gérer, comme jeter les vieux cartons, et passez progressivement à des projets plus importants, comme réorganiser les étagères.

Bref, la prochaine fois que vous serez tenté de réparer quelque chose avec l'équivalent numérique d'un cintre et du ruban adhésif, rappelez-vous : le gambiarra d'aujourd'hui est la dette technique de demain. Investir dès maintenant du temps et des ressources dans un code propre permet non seulement d'éviter des maux de tête dans le futur, mais aussi d'économiser des efforts considérables (et de l'argent) plus tard. En faisant les choses comme il faut dès le départ, vous posez les bases d'un système plus durable et adaptable. Et si vous vous sentez dépassé par la dette technique, notre équipe chez Monarq est là pour vous aider. Nous sommes spécialisés dans l'identification et la résolution de ces problèmes, afin que vos systèmes soient robustes, efficaces et prêts pour l'avenir. Gardons nos systèmes numériques en ordre !