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 Arthur Magn… Arthur bonjour.
Bonjour Benoît. Je te propose qu'on parle de la dette technique et avec cette phrase que tu
t'as dit et que j'aime beaucoup, qui me fait réfléchir qui est, mais en fait la dette technique,
il faut partir du principe qu'on n'a pas forcément besoin de la rembourser.
Exactement.
Il y a cette idée qu'une dette doit être remboursée, mais en fait dans le cadre de la
dette technique, c'est peut-être la limite de l'analogie, c'est que non,
il n'y a pas besoin de la rembourser. Qu'est-ce que tu veux dire par là, je trouve ça vachement intéressant ?
Ce qu'on voit depuis quelques temps, c'est que cette notion de dette technique apparaît de
plus en plus dans les entreprises. Donc les gens ont tendance à faire l'analogie justement et la
métaphore de la dette, comparer ça vraiment avec une dette financière, ils se disent bon,
quand je danse un outil comme sonarcube qui m'indique que j'ai 600 jours de dette technique,
ça veut dire que je dois passer 600 jours à corriger tout mon code dégassi pour arriver
à un état clean qui va pouvoir évoluer dans le temps plus facilement. Ça, c'est vraiment
quelque chose qui est complètement faux et c'est souvent ça qui va faire peur justement aux gens
qui vont lancer des outils comme sonarcube sur des projets où ils vont voir beaucoup de
dette technique, ils vont se dire bon, il y a trop de travail à faire, du coup, qu'est-ce que je fais,
je ferme cet outil et j'installe pas le linter et je vais rester comme ça parce que il y a beaucoup
trop de travail derrière. En fait, il faut voir ça vraiment comme cette notion de dette est importante
parce que quand on ne va pas réaliser de code de la meilleure manière la première fois, on va créer
une sorte de dette qui va évoluer dans le temps évidemment, qui va nous prendre plus de temps
à corriger quand on va passer beaucoup de temps à faire autre chose. Pour autant, la plupart des
parties de notre projet ne vont pas évoluer forcément dans le temps. On a peut-être des
parties qui vont rester identiques pendant des années. C'est parti de code là, ça sert à rien
d'aller les retravailler, on va juste avoir un risque de régression en fait et pour autant,
la partie du code fonctionne très bien. Donc toi, si tu n'es pas forcément favorable dès
qu'on met un linter en place, à tout mettre des cares, on arrête tout, on produit plus rien,
on remet tous les compteurs à zéro avant de commencer à rajouter, toi tu dis on va plutôt
se consacrer sur les zones qu'on a besoin de modifier en fait. C'est ça exactement. Pour moi,
ce serait un peu faire de la surqualité et ce serait complètement contre-productif parce
qu'on va passer beaucoup de temps à aller corriger du code legacy qui n'est pas forcément testé,
donc il va sûrement falloir le tester avant de modifier etc. Et pour autant, ça va créer aucune
valeur pour le client parce que ça ne va pas nous permettre d'améliorer plus rapidement les
fonctionnalités qui concernent cette partie de code-là vu qu'elles n'étaient pas forcément
censées évoluer par la suite. Donc ce qui est super important, c'est de travailler uniquement sur
des parties du code qui vont évoluer justement dans les prochains sprints ou dans les prochaines
périodes et ces parties de code-là, c'est important qu'elles soient assectées. Donc en gros,
la meilleure règle, c'est la règle du boy scout qui va dire, lorsque je passe sur un fichier qui
est dans un état un peu catastrophique, donc avec des méthodes beaucoup trop grandes, beaucoup de
conditions abriquées, des choses comme ça. Quand on passe sur ce bout de code-là, il faut le
retravailler et il faut que ce code-là soit clean. Notre évolution fonctionnelle doit apporter une
valeur technique, donc le code doit être testé, le code doit être clean, simple et très simple
justement à comprendre pour la suite. Mais pour autant, on va le faire peut-être que sur 2%
du code complet, pour autant on va peut-être corriger que quelques défauts dans son art,
alors que les 6 000 défauts qui restent vont rester présents, mais ça n'aura pas d'intérêt
de décorager parce que dans tous les cas, ces défauts vont pas impacter notre évolution du
Luciel par la suite. C'est une approche que j'aime beaucoup, que je trouve intéressante. Après,
je trouve que ce n'est pas évident dans les... typiquement dans son art. Bon, la dernière fois
que j'ai regardé le son art d'une équipe, il était assez saturé et d'un coup, tu te prends
cette espèce d'avalanche de trucs à régler et tu te dis si j'améliore de 10 trucs et que j'en ai
8 000 en attente, c'est un petit peu démotivant. C'est ça. Au niveau des développeurs,
vraiment c'est très démotivant. On a l'impression de se retrouver face à une montagne, alors que
quand on ne fait pas le focus sur tous les défauts qu'il y a dans le code, mais qu'on regarde juste
les bouts de code qu'on est en train de travailler, on va avoir l'impression de ramasser plus
justement des petites pierres, on va dire, petit à petit. Pour autant, ça aura beaucoup plus de
valeur pour la suite parce que les bouts de code qu'on est en train de travailler, s'ils doivent
évoluer par la suite, ils vont nous prendre beaucoup moins de temps parce que cela se rend plus.
Et puis en plus, il y a quelque chose que dans ce que tu dis que j'aime bien aussi, ça ne prend pas
forcément plus de temps de bien faire. Ça, c'est aussi quelque chose de qui je suis assez,
enfin c'est un peu une maximum dans laquelle je crois beaucoup. Encore faut-il savoir bien faire.
C'est vrai que pour nous, le fait de faire du code de qualité, donc vraiment simple à comprendre et
à reprendre par la suite, ça ne nous prend pas plus de temps que d'écrire une méthode de 400 lignes.
On peut très bien assez rapidement découper ce qu'on est en train de faire. Et les gens n'ont pas
encore tout ce compris, il y en a qui vont dire, faire du code de qualité, ça va nous prendre plus
de temps, donc là on va aller vite pour livrer quelque chose parce qu'on est pris par le temps.
Donc on va un peu pisser du code, on va produire beaucoup de codes, pas forcément de bonne qualité.
Pour nous, c'est vraiment une erreur. On peut toujours écrire du code qui est simple à reprendre
derrière. L'architecture sera peut-être pas la meilleure parce qu'on doit aller très vite,
il sera peut-être pas forcément 100% testé si l'équipe ne fait pas du TDD.
Mais pour autant, le code doit être clean lorsqu'il est produit.
Donc c'est vrai que pour les entreprises qui vont prendre du code égacie et qui vont travailler
sur des fichiers qui sont assez endettés, si elles ont des habitudes de développement dans lesquelles
elles vont avoir tendance à découper des méthodes trop grandes tout de suite en plusieurs petites
méthodes bien nommées, rien que ça déjà, ça nous permet de, juste en faisant des extracts
méthodes en fait avec l'IDE, ça nous permet d'avoir un code qui sera déjà beaucoup plus
compréhensible et utilisable, réutilisable par la suite. Pour autant, c'est pas quelque
chose qui va prendre du temps vraiment à l'équipe ou qui va être un investissement énorme, mais
le code source est déjà la base de ce qu'on va pouvoir faire pour améliorer la qualité.
Et bien écoute Arthur, je te remercie pour tout ça. Si les auditeurs vont en savoir plus sur
ce que tu fais, ils peuvent venir où ? Alors ils peuvent venir sur notre site web directement,
sur promais.com. Ok, merci Arthur. Merci Benoît.
Quant à toi cher auditeur, bien évidemment j'espère que tu apprécies ce podcast.
À un moment donné Arthur parlait d'extract méthodes. Si tu as envie d'en savoir un petit
peu plus sur ce que ça va venir, je t'invite dans la maison des compagnons à regarder le module
2 où justement il y a toute une partie sur ça, sur l'extract méthode,
comment on l'utilise, pour quand on l'utilise et comment est-ce qu'il permet d'améliorer la
qualité de code. C'est dans la maison des compagnons sur maison.artisandeveloper.fr. Je te remercie et je te dis à demain.