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 !
Comment mesurer la qualité de code ? Alors ça c'est une question qui revient tout le
temps en long en large, en travers. Moi j'aime bien dans Clean Code, le gars nous dit la
meilleure mesure de la qualité de code, c'est le nombre de What the fuck minute lors d'une
relacture de code. Je trouve qu'elle exprime assez bien à la fois ce côté quantitatif
et qualitatif qu'il peut y avoir dans la qualité de code. Oui je sais qu'il existe
des bouquins entiers sur la mesure de qualité et j'aimerais bien les lire d'ailleurs
pour comprendre un petit peu mieux ce que les recherches académiques nous apportent et
je suis sûr qu'il y a des choses intéressantes à travailler. Maintenant j'ai toujours trouvé
de difficile en tout cas pour l'instant dans l'expérience que j'ai eu d'avoir
une vraiment ressenti au travers de maitrisques sur le code de l'état actuel des choses.
Le code implique tellement de choses que ce soit sur le code en lui-même mais aussi
sur l'équipe qui va avec parce que finalement pour moi un morceau de code n'est pas vraiment
séparable de l'équipe qui l'a constitué et du coup en fait quand tu parles de qualité
de code tu mesure aussi la décoeition de l'équipe avec le code qui a été écrit.
Donc mesurer la qualité dans le pot de code en soi ne veut pas dire grand chose pour moi.
Et ce matin lors d'un échange avec Alex et Pierre sur leur chaîne YouTube,
j'ai eu le plaisir d'échanger avec eux et j'ai bien aimé à un moment donné Pierre à
porte cette nuance il dit la mesure de qualité c'est une des mesures de qualité c'est combien
de temps est-ce que tu passes à refaire les choses et je trouve ça vraiment super intéressant.
Mesurer ton tendriwork en fait c'est à dire le tendriwork on se comprenne bien c'est pas
tu as eu du feedback des utilisateurs qui t'amènent à refaire des choses non c'est tu as fait
quelque chose et qui marche pas bien et tu dois le changer mais pas parce que tu as eu des infos
nouvelles simplement parce qu'en fait ça va être mal fait quoi et j'ai ce souvenir une fois
j'ai déjà du temps parlé sur le podcast parce que cette tête d'indote m'a un peu traumatisé
je dois te dire. Le souvenir d'une époque où j'étais avec d'immerger dans une équipe et je propose
au cas de faire la petite feature qui était à faire en tdd tous les deux pour les aboutes trappées
ça il intégré cette pratique puis il me dit non mais ça va écraser des têtes j'en ai pas besoin
là c'est une toute petite feature et il avait raison c'était une toute petite feature ce qui fait
qu'il lui a fallu à peu près deux trois heures pour la coder mais d'ailleurs il lui a fallu pas loin
de trois jours pour la fixer et donc là je me dis ah mais c'est pas possible et là tu vas
voir là typiquement pour moi les trois jours supplémentaires c'est vraiment du tendriwork
en fait et tu peux mesurer la qualité de ton code à l'oeuvre de ça pour regarder et réfléchir
autant que tu passes dans ton équipe à faire du support à corriger des bugs je connais des
équipes qui consomment 40% j'en connais d'autres qui ont consommé à un moment donné 80% même
j'ai même souvenir d'une équipe qui avait atteint un stade on prépare ce que dire un stade terminale
en fait de l'application où il consommait 100% de leur bande passante à fixer des problèmes
et c'était pas des problèmes qui étaient discutables on n'était pas dans l'ordre du est ce que c'est
en feu en fait et on pouvait pas dire non mais on arrête on recommence parce qu'en fait il y avait
des vrais clients au bout il y avait du vrai des vrais clients du vrai argent et non il n'était pas
question d'arrêter de faire une réécriture complète ce qui aurait été peut-être salutaire pour
l'application mais j'ai un emploi du pragmatique ce n'était pas d'un point de vue opérationnel
faisable et du coup on fait comment comment tu fais le jour où où toute ta bande passante est
absorbée à régler des problèmes critiques ma petite doute bien que c'est compliqué pour
l'entreprise d'innover c'est compliqué de garder une certaine distance par rapport à
ses concurrents et tu finis par te faire croquer d'une manière ou d'une autre en fait donc j'aime bien
cette idée de mesurer la qualité de ton code par ton temps de rework alors clairement c'est une
mesure je me pose la question comment on préobjectif et ça parce que faudrait mesurer du temps c'est
toujours un truc qui est pénible pour les développeurs si en plus il faut commencer à catégoriser ton
temps à réfléchir bon ben là est ce que c'est de l'upgrade est ce que c'est du rework est ce
que c'est du est ce que c'est du du refactoring normal est ce que c'est du refactoring pas normal
je pense qu'on risque de bien se prendre la tête peut-être qu'une mesure un peu empirique au doigt
mouillé pourrait bien faire l'affaire de mesurer en fait que chacun se pose la question tiens aujourd'hui
combien de temps j'ai passé à fixer des problèmes qu'aurait pas lieu d'être si j'avais fait les
choses correctement dès le départ voilà c'est c'est quelque chose que je te propose je suis curieux
de ton retour qu'est ce que tu en penses comment tu imaginerais médecin en oeuvre si tu le mets
en oeuvre qu'elles sont un peu les insights que t'as qu'est ce que qu'est ce que tu en apprends et
qu'est ce que tu en fais ça m'intéresse énormément je t'invite à le partager sur benoît
arobase artisan developer.fr si tu peux m'écrire un email sinon je pense que tu me trouveras assez
facilement sur LinkedIn benoît aganthom voilà j'espère que cet épisode t'as plu en tout cas si
tu as envie de faire un état des lieux de tes pratiques si tu as envie de voir où tu en es je t'invite
à faire un auto diagnostic de tes pratiques sur artisan developer.fr c'est la diagnostic ou tout
simplement sur companion.artisan developer.fr et tu as un petit questionnaire avec une vingtaine
de questions qui te permet de vraiment te situer de là où tu en es et ensuite te proposer du contenu
spécifique pour toi pour t'améliorer si ça t'intéresse companion.artisan developer.fr je te
remercie de t'en écouter je te dis à bientôt