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 Main, Arthur bonjour !
Bonjour !
Comme c'est la première fois que tu viens sur le podcast, est-ce que tu peux te présenter
en une minute ?
Tout à fait. Donc moi je suis Arthur Main, je suis CTO éco-fondateur d'une startup
qui s'appelle Promise. On est basé à Bordeaux et on est spécialisé dans la qualité logicielle.
Ok et justement vous éditez un produit qui s'appelle Témy, c'est ça ?
C'est ça. En fait on suit pas mal tout ce qui se passe au niveau du software craftmanship,
des valeurs qui sont poussées par le mouvement. Et on a essayé d'intégrer ça dans une plateforme
qui est dédiée à l'équipe de développement, qui vient justement pousser ces valeurs de
collaboration, de communication autour des bonnes pratiques de code. Donc on est très
orienté, qui est une code et test en ce moment. Et surtout sur la question de comment ça
se passe à large échelle dans les entreprises, dans les entreprises où il y a plus d'une
cinquantaine de développeurs, comment est-ce qu'on fait pour uniformiser un petit peu
toutes les bonnes pratiques de développement ? Et surtout la question c'est comment est-ce
qu'on fait pour diffuser ces bonnes pratiques de développement à l'ensemble des développeurs,
à l'ensemble des équipes ?
Bon ça c'est facile, je mets en place un sonar et puis c'est réglé non ?
Justement c'est ce qu'on voit depuis, alors maintenant ça fait quatre ans qu'on existe.
On a rencontré pas mal d'entreprises qui pensaient qu'une fois qu'ils avaient mis
en place du sonar cube ou des dineteurs, ils usaient de la qualité, un peu comme les
entreprises qui mettent du Jenkins ou du Docker et qui disent qu'ils font du DevOps ou alors
celle qu'ils mettent en place du Gira et qu'ils font de la GIL. Sonar cube c'est devenu
un petit peu la même chose, on met du sonar cube et tout va être le meilleur des mondes,
on va faire de la qualité dans notre code etc. Sauf qu'en réalité ces outils de calimétrie
comme sonar cube, ils sont bien pour nous donner quelques indicateurs de codesmets dans
le droit ou dans le code justement il y a des soucis, il faudrait les reprendre mais pas forcément.
Le problème c'est que ces outils là sont souvent utilisés plutôt par des managers ou les responsables
techniques d'après ce qu'on a vu dans les entreprises et c'est des personnes qui ne sont pas
forcément dans la technique technique parce qu'ils ne sont pas vraiment super proches de l'équipe de
développement et en regardant ces tableaux de bord avec ces indicateurs qui vont être
tous rouges, qui vont remonter des centaines de jours de dette technique et beaucoup de dilation,
ils vont demander à l'équipe d'aller corriger cette dette technique et ils vont imposer des seuils
donc ce qu'on appelle des quality gate dans sonar et ils peuvent imposer des choses comme ça sur
l'ivraison en disant on veut tant de défauts maximum etc. Ce qui donne un effet très nocif dans
les équipes où on va juste là, on va juste être en train de corriger des choses en fait pour atteindre
certains seuils et on va avoir tendance à corriger un peu n'importe quoi donc des fichiers qui
ne sont pas touchés depuis des années et qui ne vont pas évoluer mais pour autant on va faire des
corrections donc on aura juste un risque de régression en fait à l'intérieur ou alors on
va aller tester un petit peu n'importe quoi pour augmenter la couverture de test pour autant
les tests seront pas pertinents et ils ne vont pas tester des choses qui sont vraiment importantes
pour le projet. En tout cas moi ce qui est clair c'est que quand je parle avec des développeurs,
j'étais en train de chercher là pendant que tu me parlais, j'en connais pas beaucoup qui me remonte
une utilisation on va dire amicale de sonarchie ou quoi c'est plutôt perçu comme le truc qui vient
casser les pieds pour parler très gentiment, qui vient les enquiquiner quand il y a une poudre
request à faire, qui vient les enquiquiner quand ils ont une mise en prode à faire et qu'il y a
ce truc au milieu là qui vient les polluer tout à fait et j'ai été assez surpris de voir qu'il
y avait pas cette dimension pétagogique en fait le truc vient de nous mettre une espèce d'énorme
truc dans la gueule avec potentiellement des cas du legacy, des quantités jusqu'au le sal de tant
de corrections, des fois tu fais le calcul et le temps de corrections qui t'annonce est supérieur
au temps qu'a déjà été dépensé pour fabriquer le logiciel. C'est souvent le cas heureusement.
Et j'ai des équipes, je me souviens d'une équipe en particulier qui m'avait ouvert leur sonar et
bon bah ok on l'a mis en place et puis il se voit quoi, il se passe quoi derrière quoi.
C'est ça en fait on a vraiment un côté contrainte qui arrive quand sonar est en place et ça peut
être perçu par l'équipe de développement comme une contrainte en fait. On développe,
il y a quelque chose qui vient de nous taper dessus quand ça respecte pas exactement la
règle qu'on avait définie alors il faut plutôt voir ça comme un...
J'ai même en tête une équipe où les qualiticiens se demandaient s'ils allaient oser mettre des
verroues justement des qualitigates quoi parce que ça avait l'air d'être un peu un sujet tabou
en interne quoi. C'est souvent une vraie conduite du changement en fait à mener avec ces outils là.
Il faut y aller de manière progressive, il faut avoir des règles qui correspondent vraiment à ce
qu'on a défini au niveau de l'équipe avec l'équipe justement en se disant bah toutes ces règles là
ça va être des faux positifs, ces règles là vont pas être importantes par contre celle là
sûrement oui mais quand on va commencer à rendre ça bloquant on va forcément avoir des faux
positifs dans ces outils et quand on commence à avoir des faux positifs, tout de suite ils sont
délaissés par les équipes de développement qui vont mettre des suppress warning dans son art
ou qui vont faire des corrections dans son art qui vont être pires que le code initial et c'est
là où on a un effet vraiment pervers parce que on va avoir des sonards qui vont être ouvert,
qui vont être tout beaux pour autant le code derrière sera très dur à reprendre et ne sera pas de
bonne qualité. C'est le principe même de sonard dans sa capacité à évaluer que tu remets en
question alors. C'est ça le problème de ces outils là en fait c'est que les règles c'est
vraiment des codes-men qui va identifier des endroits dans le code ou il y a peut-être quelque
chose qui ne va pas mais pas forcément certaines règles vont dire qu'il y a une violation à
certains endroits pour autant ce sera des faux positifs c'est pour ça que c'est bien de laisser
libre au niveau d'équipe donc c'est pas grave s'il y a des violations qui arrivent sur ces plateformes
là par contre il faut que ce soit visible au niveau d'équipe il faut que les gens puissent
communiquer là dessus et souvent les responsables de l'équipe ne laissent pas vraiment de temps à
l'équipe pour partager sur ces outils de calimétrie pour vraiment travailler dessus et comme je
l'ai dit des développeurs ne s'en servent pas trop donc c'est plutôt utilisé par des leaders
techniques ou par des managers et tant que l'équipe n'a pas repris en main un petit peu ces outils
là on a vraiment un effet où ça va juste être là pour remettre les développeurs pendant
la police c'est un peu la police c'est ça c'est pour ça que pour nous il faut vraiment qu'il y
ait une sorte d'animation qui se crée dans l'équipe sur ces plateformes là donc vraiment sur ce côté
échange et communication sur des différents traits sur différentes choses mises en place et il
faut pas chercher à aller corriger tous les défauts qu'on va voir dans le code évidemment il faut
vraiment faire la section sur des nouveaux fichiers sur des cas dont on est en train de travailler une
fois qu'on a mis en place des règles de bonne pratique sur le code on va essayer d'améliorer
petit à petit les fichiers sur des cas dont on est en train de travailler donc c'est un peu
l'arrêt du boscout ou le but c'est de rendre de fichiers plus propres que quand on est arrivé donc
on va tester dès qu'on peut évidemment si on peut faire du tdd évidemment c'est encore mieux
mais il faut vraiment voir ces outils là comme un support à l'animation autour des bonnes pratiques
de code mais il faut pas voir ça comme les outils qui vont sauver tous les projets évidemment et
magique et clé en main qui fait tout seul c'est ça c'est ça et bien écoute Arthur je te remercie
pour ta participation si les auditeurs veulent en savoir plus ils peuvent venir où ?
Il peut venir sur notre site directement sur promise.com, on parle un petit peu de ça justement
des différents indicateurs de qualité comment il peut être perçu bien ou mal et mais ce côté
plus animation et humain autour de l'équipe qui est vraiment la partie importante à mettre en avant
au niveau des équipes de développement. Merci Arthur. Merci. Quand à toi cher auditeur j'espère
que tu as apprécié ce podcast si c'est le cas je t'invite à nous rejoindre dans la maison des
compagnons maison.artisandeveloper.fr tu y trouveras tout un ensemble de formations pour t'accompagner
justement à progresser sur le chemin de l'artisanat logiciel. Je te remercie, je te dis à demain.