Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Philippe Krüsten. Philippe bonjour.
Bonjour.
Comme c'est la première fois que tu passes sur le podcast, est-ce que tu peux te présenter en une minute ?
Je m'appelle Philippe Krüsten, je suis ingénieur logiciel. J'ai grandi à Strasbourg et depuis 40 ans maintenant,
j'ai visité le monde en tant que consultant technique.
Initialement je travaillais pour Alcatel et puis ensuite pour Rational Software, brièvement pour IBM.
Et mon boulot de retraité, je suis prof dans une école d'ingénieur au Canada, l'université de Colombie-Britannique, avant couvert.
Ok. Et aujourd'hui on t'intervieu dans le cadre de la battle.
Avec cette question en ligne de fond, est-ce que du code de qualité coûte plus cher ?
Alors je me suis dit que comme la dette était vraiment ton dadal, la notion de dette technique,
tu avais probablement un bout de réponse à cette question. Qu'est-ce que cette question t'inspire ?
Ok. Développer du logiciel de qualité coûte plus cher que développer du logiciel de pas de mauvaise qualité.
Il faut pas être naïf. Il n'y a pas de snow-free lunch, comme on dit en anglais.
Mais il y a des aspects subtils parce qu'on peut éventuellement faire des économies à un moment donné
pour livrer quelque chose à un coût relativement modeste, mais en accumulant de la mauvaise qualité cachée.
Et c'est un peu le sujet qui m'a intéressé ces dix dernières années, quelque chose qu'on a décidé d'appeler dette technique.
Alors qu'est-ce que c'est que la dette technique ? Si on regarde la qualité en général, la qualité a deux aspects.
Il y a une qualité externe, la qualité qui est visible des usagers, des gens qui installent, des gens qui supportent, etc.
Et il y a une qualité interne qui n'est visible que par les développeurs.
Cette qualité interne, on peut éventuellement la négliger.
On peut se dire, oui, essayons de faire quelque chose rapidement.
On règlera ça plus tard, on arrangera ça plus tard.
Et puis si on n'arrange pas ça plus tard, eh bien on va en souffrir.
Et cette manque de qualité interne devient de plus en plus lourde et de plus en plus pesante.
Et lorsque l'on a des grands systèmes ou des systèmes qui ont une longue durée de vie, ils sont de plus en plus difficiles à évoluer.
Et donc il y a un aspect assez subtil de différer dans le temps le coût de mauvaise qualité.
Et ce coût là, à un moment donné, ce qui finit pas par te coûter plus cher,
parce que l'idée que j'en ai, c'est que ça devient exponentiel, ces trucs-là.
À un moment donné, tu perds.
Pour moi, je corrompe la dette à... Est-ce que tu as la maîtrise de ton code
et est-ce que tu as la capacité à le faire évoluer en fait ?
Est-ce que ça évolue de façon exponentielle ? C'est difficile à dire.
C'est pas exactement le même modèle qu'une hypothèque sur une maison, avec des intérêts fixes
ou une dette sur une carte de crédit avec des intérêts importants et fixes.
Il n'y a pas de pourcentage et donc il n'y a pas nécessairement une accumulation exponentielle.
La dette technique en logiciel, elle a la particularité de prendre de forme.
Il y a une dette potentielle et une dette réelle.
La dette potentielle, c'est toutes les imperfections que l'on a dans le code
ou dans la structure ou l'architecture du logiciel, ou même des documents connex,
l'absence de documentation, l'absence de suite de récréation de tests, etc.
Mais si on a du logiciel qui est relativement stable, qui n'évolue pas,
peu importe qu'il y ait de la dette technique dedans.
Alors que si on a des modules, des sous-systems qui évoluent constamment,
d'avoir de la dette technique, effectivement, là, ça s'accumule de plus en plus
parce qu'on va avoir une espèce de raccourci, un workaround sur du code qui n'est pas de bonne qualité.
Et petit à petit, cette mauvaise qualité interne qui n'était pas visible devient visible
parce que la mauvaise qualité interne va se transformer au bout d'un certain temps en mauvaise qualité externe.
Si le système quelques années plus tard voit d'autres développeurs arriver
qui ne vont pas comprendre la petite astuce qu'on a introduit dans le logiciel,
ils vont développer quelque chose de... va se traduire par de la mauvaise qualité externe.
Donc oui, ça s'accumule... Est-ce que ça s'accumule de façon exponentielle ?
Non, ça dépend aussi de l'attitude de l'équipe de développement vis-à-vis de la dette technique.
Il y a des équipes de développement qui de temps en temps réduisent leur dette technique,
ou au début d'un cycle de développement, commence par analyser, résoudre un petit peu et rembourser,
pour conserver l'analogie financière, rembourser une partie de leur dette technique.
Et donc la lait c'est relativement plate au cours du temps.
Et l'image que ça me donne, tu vois, c'est un petit peu comme nos émissions carbone,
on se les prend avec un effet d'inertie, et du coup quand on se les prend,
ça devient de plus en plus difficile de les gérer.
Et la question que je me pose, c'est, comment est-ce qu'on peut rendre visible cette non qualité interne, en fait,
potentielle ou avérée d'après toi ?
Bon, ça dépend un peu de la nature de la dette technique.
Il y a une espèce de spectre de dette technique.
Il y a de la dette technique qui est vraiment au niveau du code.
Et là, il y a des tas d'outils, des statistiques à dans la isole, je ne sais pas comment dire en français,
des analyseurs statiques, des tas d'outils qui vont regarder ton code et pointer sur des faux potentiels.
Est-ce que tu as une métrique ou deux préférées là-dessus ?
Ce n'est pas une question de métrique, c'est une question de détection et de pointer sur des endroits qui sont suspects de mauvaise qualité.
Par exemple, d'avoir beaucoup de clones du code ou quelqu'un a fait sélect, copy, paste, pacepace,
modify, pacepace, modify, point, modify, pacepace.
Ça, c'est un exemple, si tu veux, de dette technique au niveau du code,
parce que quelques mois plus tard, va trouver deux, trois de ces instances,
mais ne sait pas qu'il y a quinze instances de ce cut and paste.
Donc, des analyseurs statiques vont te pointer sur des endroits ou des modules ou des sous-systems qui contiennent beaucoup de dette technique.
Mais l'autre aspect, à l'autre extrémité du spectre, c'est au niveau de la structure, des outils, des frameworks,
l'architecture du système, la structure du système.
Là, en général, le mieux, c'est de poser la question au développeur, eux-mêmes.
Qu'est-ce que vous regrettez beaucoup aujourd'hui d'avoir fait avec le système ?
Lorsque je pose cette question, c'est, ah oui, tout au début, on a fait ci, on a choisi ça,
ça, ça représente la dette technique.
Mais elle est essentiellement dans la tête des développeurs ou ceux qui sont encore associés au système.
Naturellement, c'est très difficile à détecter lorsque tous les gens qui ont fait la conception initiale
ont migré vers des espaces plus verts.
Il y a d'autres aspects sur la dette technique un peu connexe,
c'est-à-dire l'absence de documentation, l'absence de tests.
Ça, c'est un peu plus difficile.
Il y a aussi de la dette technique qui s'accumule dans l'infrastructure.
Tous les scripts utilisés pour le déploiement du logiciel, par exemple,
les gens ne se rendent pas compte souvent que ces scripts doivent être maintenus.
Il y a beaucoup de qualités internes perdues dans tous les outils de déploiement du logiciel.
Ceci est apparu beaucoup avec le concept de DevOps et le concept de pouvoir faire du déploiement
en continu des applications logicielles.
Et si tu devais donner un conseil à un manager, à une équipe, à un tag lead,
à quelqu'un qui prend conscience un petit peu de ces enjeux et qui se dit
« J'ai vraiment envie de faire quelque chose, mais je ne sais pas trop par où commencer ».
Qu'est-ce que tu lui conseillerais de faire ?
Informer, décrire la dette technique, la décrire en termes concrets,
c'est-à-dire en utilisant des exemples de leur propre système,
et mettre en place un processus pour identifier la dette technique, la triée,
quelle est la dette technique dont on souffre, quelle est la dette technique qu'on peut laisser en place.
Ce n'est pas très difficile.
C'est une question de, je dirais, comme utiliser une expression anglaise,
conduire les yeux ouverts.
L'étape suivante, c'est de trouver des bons instruments,
c'est-à-dire trouver par exemple des analyses statiques pour analyser la dette technique.
L'étape suivante, c'est d'éviter d'accumuler de la dette technique.
C'est un peu plus difficile parce que très souvent, les développeurs
ont des contraintes de faire une release à une date donnée, etc.
C'est très difficile d'éviter de se trouver dans une situation
où on peut construire un système sans prendre aucune dette technique.
Mais avec un peu de discipline et de la communication,
on arrive à améliorer les choses et réduire l'accumulation de nouvelles dettes techniques.
Ok Philippe, merci beaucoup pour ton apport et ce point de vue.
Merci d'être venu aujourd'hui.
Merci, benoît.
Quant à toi, chère auditeurs, j'espère que ce podcast t'a plu.
Si tu penses comme Philippe que oui, du code de qualité coûte plus cher,
viens le dire dans l'AREN, aren.artisan-developpeur.fr
et si tu penses le contraire, viens le dire aussi aren.artisan-developpeur.fr.
Je te remercie et je te dis à demain.