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 Mign, Arthur bonjour. Bonjour Benoît. Est-ce que tu pourrais te
présenter en quelques mots pour ceux qui ne te connaîtraient pas ? Alors moi je suis Arthur Mign,
donc je suis CTO et co-fondateur d'une startup qui a été créée à Bordeaux qui s'appelle ProMize.
ProMize est une startup spécialisée dans tout ce qui va être définition et diffusion des
bonnes pratiques de développement dans les équipes de dev de n'importe quel taille.
Et justement ça tombe bien, le sujet du jour c'est la gestion des connaissances. Tu me proposais
qu'on aborde cette question là de comment est-ce qu'on diffuse des bonnes pratiques,
comment est-ce qu'on s'assure que les choses sont transmises dans les équipes. Et personnellement
je trouve que c'est une question absolument passionnante et c'est pas une blague. Je trouve
ça vraiment cette question super intéressante de comment est-ce que tu fais finalement pour harmoniser
le niveau, permettre aux gens de grandir, permettre aux gens de s'élever, permettre à la connaissance
de circuler en fait tout simplement. Moi je me rappelle avoir tapé des bouquins de knowledge
management, de gestion de connaissance. Il y a un vrai sujet, surtout qu'en plus il y a un truc un
petit peu spécial dans notre métier, c'est qu'on travaille sur un peu de code qui est commun,
c'est un peu une espèce de commun, c'est quoi tu vois de commun comme tu pourrais dire l'air c'est
un commun, la rivière c'est un commun, mais à l'échelle de l'entreprise le peu de code central
est un espèce de commun qu'il faut apprendre à gérer à plusieurs comme une géante colocation.
Qu'est ce que tu as toi comme retour d'expérience sur les bonnes pratiques que tu vends d'entreprises
pour gérer ça ? C'est vrai que depuis cinq ans maintenant on a vu beaucoup de contextes différents
que ce soit des USN, des clients finaux, des startups, des PME etc. Mais souvent cette question
revient de comment est-ce qu'on fait pour partager justement cette connaissance entre les équipes
ou alors même au sein d'une même équipe pour aligner un petit peu les connaissances des
développeurs et qu'on n'est pas ce côté héros on va dire, une personne qui connaît tout sur
la sécurité, une personne qui connaît tout sur le Java ou du Angular et c'est toujours cette
personne là qu'on va souhaiter quand on a une question. C'est vraiment un effet que des entreprises
essayent d'éviter en partageant justement la connaissance de ces personnes là au reste de l'équipe
et c'est vrai que depuis des années maintenant ce qu'on voit beaucoup c'est surtout tout ce qui va
tourner autour des revues de code par exemple. Beaucoup de revues de code sont organisées dans
les équipes dans le but justement de faire monter en compétence ces différents développeurs. Le
problème c'est que le format des revues de code pour nous il n'est pas forcément le plus adapté
pour vraiment définir ensemble en équipe des bonnes pratiques et des diffuser à d'autres équipes.
Souvent ces revues de code en fait elles sont faites par des seniors qui ont fait des revues à des
gens un peu plus juniors donc c'est dommage ça va que dans un sens. On capitalise pas vraiment
sur tout ce qui va être mis en avant pendant ces revues parce que les commentaires vont être
perdu une fois que le code va être mergé donc c'est vrai que tout ce qui va être mis dans les
commentaires ça va être donné à une seule personne et ensuite on va les perdre et on va
avoir du mal à se mettre d'accord évidemment en équipe en fait sur sur des bonnes pratiques
adoptées et sur vraiment ce côté amélioration continue en disant est ce que ce qu'on fait
aujourd'hui on pourrait pas le faire encore mieux. Et depuis un an du coup on a essayé de mettre en
place un nouveau format dans les équipes de développement. Un format qui est complémentaire
au revue de code évidemment faut surtout pas les arrêter si vous en faites. C'est un format
qu'on a appelé des ateliers craft. Ce format en fait il va permettre aux équipes de discuter
vraiment de leur code récent et de ce qu'ils ont mis en place au niveau de leur bonne pratique.
Et ça va vraiment permettre aux développeurs de se mettre d'accord justement sur des
bonnes manières de faire et ça va permettre évidemment de partager de la connaissance
entre les développeurs différentes équipes. Je vous présente un petit peu le format.
Et concrètement comment ça se passe ? Le format en fait ça va être sur une semaine
ou sur deux semaines on va commencer par sélectionner quelques fichiers de code source
dans l'équipe donc évidemment pas de code dégassis ça aurait pas vraiment de sens.
Il faut sélectionner en général moins de trois contrairement au revue de code on prend pas
vraiment tout le code on va juste prendre un échantillon récent qui est assez pertinent.
Pendant la semaine pendant les deux semaines tous les développeurs vont aller pouvoir identifier
des choses qui sont bien faites dans ces fichiers des choses qui vraiment leur paraissent le plus
pertinent et à l'inverse des choses qui seraient améliorables donc c'est des bonnes pratiques
qui n'ont pas encore été mis en place par exemple. Donc tous les développeurs peuvent faire ça
en qu'on soit junior ou senior ou stagiaire ou éternant ou n'importe qui. L'idée c'est que
tout le monde puisse proposer des choses justement sur ces fichiers. On peut également
faire depuis notre idée donc on a développé en fait une plateforme qu'on a appelée Promise
comme la startup qui permet d'être un support vraiment à ces ateliers donc de pouvoir aller
identifier des pratiques directement sur des fichiers sectionnés et également on a développé
des plugins pour les idées par exemple pour aller pendant qu'on développe créer des nouvelles
pratiques, mettre en avant des refactoring qu'on aurait fait sur de code, mettre en avant des choses
bien, des choses moins bien et l'idée en fait ça va être à la fin de ces deux semaines de faire
un point avec toute équipe aujourd'hui sortons en visio parce qu'avec le télétravail évidemment
toutes les équipes sont en visio mais en fait une personne de l'équipe va partager son écran,
va présenter des fichiers avec toutes les pratiques qui ont été identifiées par tout le monde et on
va passer sur toutes les pratiques identifiées et la personne qui a mis en avant cette pratique va
pouvoir prendre la parole et dire bah pourquoi est-ce qu'elle a trouvé que c'était une chose bien
faite ou une chose améliorable et qu'est ce qu'elle aurait proposé justement c'est
quelque chose d'améliorable évidemment on peut proposer des améliorations et donc elle va pouvoir
montrer à l'équipe comment elle aurait mieux géré par exemple les cas d'erreur,
comment elle aurait, comment elle serait servi de son frémoire cangudard,
comment elle aurait géré ses quatre tests etc. Des pratiques identifiées en fait sont sur des
sujets assez différents ça peut être des pratiques clean code, ça peut être des pratiques de
test, ça peut être des pratiques d'architecture, ça peut être des pratiques de nommage,
des pratiques de BDD, des choses comme ça. On voit un peu tout mais le point qui est important
c'est que là c'est vraiment l'équipe elle-même qui va définir ses propres bonnes pratiques donc
on va pas forcément retrouver les mêmes choses en fait d'une entreprise à l'autre mais vu que
c'est d'équipe qui identifie ses propres bonnes pratiques bah elle a tout de suite tendance à
beaucoup plus les suivre et les monitorer, les manager justement ses pratiques parce que c'est
les siennes et c'est pas un référentiel de 200 pratiques qui lui tombe sur le coin de la tête
comme ça c'est vraiment elle en fait qui va définir ses manières de faire. Donc si je récapitule
toutes les deux semaines l'équipe se réunit, chacun a travaillé sur quelques morceaux de code
qui ont été sélectionnés et il y a un travail d'identification de ce qu'on trouve être des
bonnes pratiques ou des choses pas terribles et ensuite on en parle tous ensemble et on lit
l'itère comme ça c'est ça ? Oui c'est ça on en discute ensemble on se met d'accord si jamais
il y a une pratique qui fait pas consensus on peut lancer ce qu'on appelle une battle sur des pratiques
et pendant la semaine suivante en fait tous les développeurs vont pouvoir voter ce que je suis
plutôt pour ou contre cette pratique évidemment on peut mettre des arguments en disant pourquoi je
serais plutôt pour ou pourquoi je serais plutôt contre et en fait le but de ces bâteuses c'est
que souvent des personnes vont aller trouver des alternatives à des manières de faire en disant
bah c'était peut-être pas mal de faire ces extractions de méthodes là mais en fait on aurait pu
extraire un composant utilitaire ça serait quelque chose par exemple de plus efficace parce que ça
pourrait être utilisé par d'autres projets et c'est vraiment ça qui parait intéressant c'est
pas forcément les pratiques identifiées de base dans les fichiers c'est vraiment les discussions
qu'on va avoir autour et le but c'est que ces discussions durent donc la rétrospective elle est
là pour durer une heure c'est quelque chose qui est timeboxer dans le temps mais il faut vraiment
laisser des discussions en fait dès qu'on tombe sur un sujet qui est assez important comme la gestion
d'erreur ou des choses comme ça on va pouvoir creuser en fait et les pratiques identifiées c'est
plus un sujet de discussion qui a été mis en avant du coup pendant la semaine mais derrière on va le
creuser ce sujet de discussion et ça va nous amener à rebondir sur d'autres points qui vont être
un peu plus précis qui vont parler d'architecture ou de structure ou d'autres choses et c'est là
où ça devient intéressant en fait c'est juste d'avoir un point d'échange technique avec l'équipe
vraiment dédié à nos bonnes pratiques et à ce côté amélioration continue de ce qu'on peut faire
parce que ce que j'aime dans ce que tu décris c'est le côté c'est le côté on va le risquer
bien autant que ce qui est améliorable ça je trouve que c'est déjà hyper positif il y a un truc
aussi que je trouve intéressant qui est c'est l'équipe qui se forge son propre référentiel ça c'est
le meilleur moyen de tout simplement de faciliter l'adoption j'aime bien l'idée des battles après
la question que je me pose c'est comment tu fais s'il y a vraiment quelque chose qui clash ou qui
pose problème tu vois je sais cette espèce de souvenir éternelle de il y a deux questions il y a
deux types de questions il y a des questions qui sont qui sont juste pas pas objectifs tu vois qui
sont totalement objectifs typiquement est ce qu'on met les semi que les les accolades en fin de ligne
ou en début de ligne suivante je me rappelle dans une ancienne expérience ça avait été un sujet
épineux et donc ça à un moment donné faut juste décider toi il y a juste une combation à prendre
et décider et puis tu as des sujets un peu plus profonds sur où il y a un vrai choix à faire
parce qu'il y a un compromis et là il n'y a pas de réponse parfaite quoi du coup comment tu
c'est quoi les bonnes pratiques que tu vois là du coup d'organisation d'animation pour aider à
résoudre ces problèmes là quand les gens même imaginons tu fasses une bataille et puis tu te
retrouve avec quelque chose où vraiment le groupe est sain d'air en deux ou alors il y a des gens
dans ceux qui sont contre et minoritaires qui sont particulièrement vindicatifs comment tu viens
à bout de ces de ce genre de conflit alors il y a il y a plusieurs cas en fait qu'on a pu voir
dans les équipes le premier ce serait d'avoir une pratique en battle et en fait tu as un tech lead
par exemple qui va dire bah en fait surtout les autres projets on a fait comme ça donc on va
trancher on va faire un peu pareil que dans les autres projets parce que c'était quelque chose
qui est qui a très bien fonctionné dans le temps etc donc c'est peut-être l'expérience qui peut
parler en premier ce qui est important c'est toujours de se mettre d'accord évidemment et de pas laisser
la moitié d'équipe faire faire d'une manière à plus d'autres moitié d'équipe faire différemment
mais le point vraiment important c'est que tous les cas de battle ont été souvent sur des
sujets très importants et très rarement justement sur l'histoire de semicolon etc qu'on pourrait
traiter avec un sonar cube en fait toutes ces petites pratiques on va dire en général sont
sont validées assez rapidement et après quand il y a des pratiques qui sont un peu plus complexes
justement où on sait pas trop quand est ce qu'il faudrait appliquer quand est ce qu'il faudrait
pas l'appliquer souvent ce qui est intéressant c'est que la pratique est bien et elle va être validée
par l'équipe par contre dans sa description on va pouvoir expliquer que c'est quelque chose qui est
bien mais il faut être pragmatique en étant développeur on doit être pragmatique donc on
doit pas l'appliquer bêtement toujours on est le cas aujourd'hui par exemple avec une équipe qui a
mis en avant des pratiques sur la documentation en java et certaines personnes disaient ben est ce
qu'il faut tout documenter ou est ce qu'il faut documenter les méthodes qui seraient qui seraient
assez complexes et qu'on ne pourrait pas vraiment exprimer avec un hommage etc et ça montre bien
qu'on va pas dire on va pas faire une pratique qui sera il faut documenter toutes les méthodes
ce serait un peu idiot par contre la pratique qu'on a mis en place on l'a renommé en fait la pratique
de base en disant ben il faut renommer enfin il faut documenter pardon les méthodes si elles
peuvent pas s'exprimer par elle-même et que là on est vraiment sur des cas métiers assez poussés
et dans ce cas là on peut évidemment documenter la méthode il faut la documenter donc voilà
c'est pour cette équipe là c'est ce qui a été défini d'autres équipes vont dire on veut jamais
de commentaires et on va absolument que le code soit il puisse s'exprimer par lui-même etc donc
c'est ça qui est intéressant c'est que ça va vraiment dépendre des différentes équipes mais
souvent ce qu'on obtient c'est un résultat où les pratiques vont devoir être appliqués de
manière pragmatique il faut pas les appliquer bêtement en fait ces pratiques et c'est là où
contrairement à des outils comme sonarcub qui va peut-être identifier beaucoup de faux
positifs sur le projet vu que là c'est des humains en fait c'est d'équipe qui va aller
identifier elle-même est ce que des pratiques sont bien appliqués ou pas sur les différents
fichiers sur lesquels on passe on a moins ce côté faux positif et justement on est moins absolus en
disant des pratiques faut pas les appliquer tout le temps de manière bête et méchante il faut
vraiment essayer de faire ce qui de manière pragmatique est plus efficace et plus utile pour le
projet tu vois en t'écoutant on est en et je crois en t'écoutant je me rends compte que ces
histoires d'un revue de code c'est toujours quelque chose qui m'a dérangé et et je commence à avoir
un avis de plus en plus tranché sur ça c'est je trouve que finalement on passe de beaucoup
de temps à faire ces choses là et si tu veux le faire bien moi je vois des boîtes qui essayent de
passer de l'énergie à grand renfort de bbl et de réunion autour des conventions de code et
finalement l'échange qu'on est en train d'avoir ne fait que nourrir ma conviction encore plus que
la meilleure manière de transmettre la connaissance ça reste le binommage dans notre métier et que
dès lors que tu désynchronise le moment où tu écris le code ça génère en fait plein de choses
en casquette derrière pour réassurer une forme de synchronisation que je trouve parfois ridicule
j'ai vu des boîtes où pour valider une paire il fallait tu vois un code qui a mis une heure à être
écrit il fallait parfois jusqu'à deux à trois heures pour valider la paire tu vois et là je me
dis mais c'est juste ridicule en fait si on avait juste mis deux développeurs devant l'ordi c'est
dire si le mec qui allait valider la paire et il avait fait il avait codé avec le gars en même temps
qu'il était en train de coder on aurait juste gagné trois fois plus d'autres on aurait juste
gagné diviser le temps de la paire par trois qu'en fait et c'est vraiment une idée qui me qui me
qui se qui se figent un peu plus dans ma tête donnera peut-être une idée de vidéo youtube
ouvera mais je pense que le monde n'est pas prêt à ça encore je je connais très très peu d'entreprises
qui sont réellement prêts à faire du travail en fait les entreprises et même les développeurs
tu vois je me rends compte que le binommage un vrai bidu ce que j'appelle du vrai binommage c'est à
dire tu arrives le matin tu sais pas forcément avec qui tu vas binommé et puis c'est parti on a une tâche
à faire et on le fait systématiquement à deux et il n'y a pas de petit âge ou de grosses tâches
ou de choses importantes ou choses pas importantes c'est juste on bosse tout le temps à deux je me
rends compte qu'en fait très peu de boîtes sont prêtes à le faire et très peu de développeurs sont
prêts à le faire on est tombés sur des contextes où justement ils font beaucoup de per programming
et de mobs programming également ce qui est ce qui est encore plus intéressant et ce qui est
intéressant c'est que justement les développeurs en fait qui font du per ou du mobs vont aller créer
des pratiques dans leur idee justement pour pouvoir les envoyer donc sur la plateforme
promise dans le but en fait d'en discuter une fois toutes et deux semaines mais avec ce qui vont
appeler des communautés de pratique en interne c'est à dire des développeurs qui seraient dans
d'autres projets dans d'autres équipes internes mais qui travailleraient sur les mêmes techniques sur
du android sur du java sur du angular par exemple et en fait de ces ateliers craft dont on parlait
ne vont être fait qu'au niveau des communautés de pratique et par contre les équipes vont faire
que du per programming et du mobs programming donc c'est des contextes assez rares mais mais
les contextes sur lesquels on est tombé justement où les équipes fonctionnaient comme ça c'était
très bien parce que les bonnes pratiques sont partagées via ces communautés de pratiques et via
ces ateliers qui sont faits une fois par semaine une fois toutes et deux semaines et pour autant les
développeurs poussent de la connaissance pendant qu'ils travaillent en per ou en mobs programming dans
leur quotidien. Ok donc ce que tu dis c'est qu'en fait le binommage et le bain permettait à l'échelle
de l'équipe de diffuser la connaissance et de s'harmoniser et après il y avait une espèce de
notion d'essaymage inter-équipe pour partager entre les équipes ce que les gens trouvaient
pertinent c'est ça ? C'est exactement ça parce que le per et le mobs ça par contre j'ai pas vu
d'endroit en fait où ça ça cassait les silos on va dire des équipes. Non des équipes ouais il faudrait
que les gens se déplace en fait et c'est plutôt rare en fait. Ouais surtout quand on travaille sur
projets assez différents c'est un peu compliqué par contre là où deviennent intéressants ces
communautés de pratique et ces ateliers qui peuvent être fait de manière régulière une fois par
semaine une fois toutes et deux semaines c'est qu'on va pouvoir parler de bonnes pratiques sur de
même langage avec des gens qui travaillent pas avec nous d'habitude qui sont peut-être dans un
autre pays on a des contextes justement avec des équipes à Bordeaux à Paris à Barcelone ou
ailleurs et des personnes travaillent sur la même technique nous en frontent donc en fait ils ne
parlaient pas forcément énormément et le fait de faire ces ateliers justement ils ont pu aligner
plein de choses en disant tiens mais la gestion des traductions par exemple on le fait avec
têtes systèmes qu'on a développées mais les autres n'étaient pas au courant donc ça permet
justement de faire communiquer des gens qui qui ont les mêmes problématiques mais qui se parle
pas forcément c'est super important d'avoir ces points d'échange dans ce qu'on appelle des
communautés de pratique un petit peu en interne. Eh bah écoute Arthur merci pour tout ça je te
propose que ce soit le mot de la fin si les auditeurs veulent découvrir son outil et peut-être expérimenter
justement dans une revue de code comment est-ce que comment est-ce qu'ils peuvent s'y prendre. Alors
la version SAS notre outil est gratuite donc elle peut être utilisée directement depuis notre site
web en fait qui s'appelle Promise donc il faut taper Promise P-R-O-M-Y-Z-E un orthographe un
petit peu compliqué et on a également donc des plug-in de revue de code pour GitStab Azure et
Bitbucket et des plug-in IDE pour VS Code Visual Studio et la suite Jetprime tout ce qui est un
point gratuit et sont disponibles directement depuis les Marketplace des IDE ou les Marketplace de
Chrome ou Firefox si vous voulez le plug-in directement. Et comment tu gagnes ta vie ici tout ça c'est
gratuit. Alors c'est gratuit dans la version SAS jusqu'à cinq utilisateurs ensuite ce qu'on propose
nous c'est plus un accompagnement des équipes justement pour des grosses entreprises on va
structurer justement ces ateliers craft on va accompagner les équipes à animer ces ateliers
craft avec la plateforme en support mais le but ça va être vraiment de créer cette animation
en fait avec ce format d'échange et c'est un format qui va s'adapter à chaque contexte et c'est
vraiment ce qu'on propose aujourd'hui en ce d'entreprise c'est de s'assurer justement que ce format
passe bien avec les gens après-midi que donne boarding de nouveaux développeurs se fait très
facilement et qui peuvent vraiment diffuser cette connaissance de manière assez efficace.
Mais écoute merci beaucoup Arthur. Merci à toi Benoît. Quand à toi cher auditeur si tu
as envie d'apprendre à écrire du code durable si tu as envie d'être fier de ton code et d'apprendre
quelques bases de bonne pratique pour justement écrire un code facile à partager et à faire
évoluer et dans lequel il fait bon vivre je t'invite à devenir découvrir le cursus artisan
développeur dans la maison des compagnons sur maison.artisandeveloppeur.fr. Je te dis merci et
je te dis à bientôt. Ciao !