Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante.
Prêts à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Jérémy Le Massu, Jérémy bonjour.
Bonjour.
Rien à voir sur le podcast, est-ce que tu peux te présenter en quelques mots pour ceux
qui ne te connaîtraient pas ?
Ok, alors du coup, j'ai Jérémy Le Massu, je suis un développeur de Vien-Norayles depuis
2008 à peu près où j'ai commencé à fermer les premières armes et actuellement je
travaille pour l'entreprise Efi qui fait de la rénovation énergétique auprès des
particuliers.
Cool.
Et le sujet du jour, dans les sujets qu'on a pu éborder, je trouve qu'il y en a un qui
était, qui n'est pas assez évoqué en fait et qui mérite qu'on comprenne un petit
moment pour en parler plus.
C'est celui autour du linter et de l'usage du linter.
Et je trouve intéressant que tu partages un peu un retour d'expérience de comment
vous le mettez en œuvre dans ta boîte.
Déjà on peut peut-être remettre en avant qu'est-ce que c'est un linter et comment
c'est quoi l'intention derrière d'utiliser un linter.
Ok, ok.
Bon alors du coup le linter, ça va être un petit outil sous joueur, sous la forme
d'une librairie qui va prendre en compte ou pas un fichier de configuration, en général
les ordres propres et défauts qui vont correspondre à ceux du langage initial sur lesquels ils
sont natifs et qui va permettre en fait de fixer un ensemble de règles, par exemple
dire ça peut être tout à l'apporte quoi est-ce qu'on utilise du plus simple des
doublespaces, enfin les softtabs ou le doublespace ou une tabulation sur les inventations.
C'est des petites choses comme ça qui font que du coup derrière ça va éviter que quand
quelqu'un fait pouche un commit avec son éditeur et configuré par exemple en table, que ça
modifie tout le fichier qui a été édité au niveau du code et que du coup on se retrouve
avec 3 minutes, 3 millions de changements alors qu'on aurait été à changer juste de
ligne pour rajouter un ordre ou quelque chose de vraiment stupide et donc du coup pour
permettre d'harmoniser un peu et d'avoir aussi des commits qui soient beaucoup plus
comment dire, qui ciblent vraiment en fait ce qui a été modifié et qui ne vient pas
donner un petit fichier anti et qui a été édité juste parce qu'on a refait ces espaces
par état, du coup on va utiliser les vinteurs pour ce genre de cas, après il existe aussi
d'autres cas c'est pour créer par exemple de la cohésion on va dire au niveau du code,
permettre aussi que du coup toute l'équipe travaille de la même manière en termes de
grammaire on va dire, de grammaire et d'orthographe au niveau du code,
sur la façon du coup de formuler les mettre aux valeurs numériques, par exemple on peut
utiliser des underscores pour séparer les milliers, on va pouvoir dire maintenant tout
le nombre de numériques on va laisser séparer avec des underscores dans tout le code,
dès qu'on a besoin de définir ce genre de valeur et ensuite en fait il va y avoir
toutes les règles de retour à l'ing, il peut y avoir aussi... En fait là tu m'évoques des règles
de formatage, il y a les règles de nommage, tu peux intégrer aussi de la calimétrie dedans tu
peux mettre des règles sur les tailles des fonctions, des objets et je crois que tu peux même,
alors j'avais vu ça, j'avais vu qu'il y avait des lineteurs qui commençaient à être capable de
comprendre le design en fait et de t'engueuler quand certaines règles étaient violées,
on se fait des parispectés. Oui, dès le moment où il y a des offences qui apparaissent,
nous en règle générale, enfin en règle générale même pas, c'est intégré dans notre signaire,
c'est-à-dire que tout comique qu'on va envoyer, tout poche qu'on va envoyer sur notre projet,
il va, on va exécuter du coup en fait justement le lineteur qui va bloquer toute
exécution par la suite des tests ou ce genre de choses ou des déploiements, parce qu'on veut
vraiment que ce soit une opération qui fait une opération, quelque chose qui soit vraiment
appliqué, c'est vraiment important pour l'équipe, que ce soit même une petite ou une grande équipe,
encore plus à grande chère, parce que du coup derrière on pense et on code un peu de la même
façon, déjà comme on l'utilise en règle, en expression convention ou leur configuration,
voilà en fait on définit les confronctions d'équipe, on a une configuration effectivement qui
définit les règles, qui permet du coup de les appliquer derrière dans ces copes qui viennent
dure, bah non, ça passe pas, nous on n'exécute pas plus loin, parce que le code ne répond pas
au standard défini par l'équipe, enfin au projet. Et comment, alors la grande question,
parce que ça je pense que les gens comprennent et moi je l'ai vécu plusieurs fois en fait,
où les gens comprennent l'intérêt de mettre un lineteur en place, ils se sont d'accord sur le
fait qu'il faille un mettre un, par contre au moment où on définit ces fameuses règles,
c'est là où les achepements arrivent, parce que on peut avoir des préférences personnelles,
on peut avoir des convictions personnelles au-delà de préférence, tu vois j'avais été très amusé
de voir que sur Java par exemple il n'y avait pas de standard officiel, il y avait celui de son,
il y avait celui d'un tel, et qu'ils étaient d'ailleurs pas tous compatibles loin de là,
et du coup comment est-ce que tu fais vivre ça en internet, comment est-ce que tu l'as mis en place,
est-ce que tu as participé à la mise en place du truc ou quand tu arrivais déjà c'était là ?
Non en fait c'est un mention développeur à qui j'ai travaillé, qui est arrivé dans l'entreprise
qui m'a suivi peu de temps après et qui avait bien aimé ça et qui a choisi de les intégrer
justement pour créer de la cohésion parce que sinon en fait chacun codé comme il voulait en
définissant soit un peu partout des choses plutôt que d'harmoniser et de vraiment créer une...
On sort, on est d'accord que c'est horrible et le lineteur est un des outils qui permettent
d'atteindre ça, c'est loin d'être le seul mais il est d'ailleurs pas suffisant mais en tout cas il
se mérite sur ce qui s'est bien fait d'être redoutable en fait d'efficacité et du coup comment
s'est fait assez la mise en place ? Vous étiez combien dans la team à l'époque ? 5 ou 6 je crois.
Ouais commence déjà à faire une bonne team, il y a largement de quoi avoir des gens qui ont des
avis diviens en genre. Justement l'équipe est assez divers et varié puisque là actuellement on
a deux juniors, on est trois seniors plus on a qu'à une recruc et partie mais du coup on a un peu
homogène on va dire relativement en termes d'équipe et du coup on se retrouve avec des juniors qui vont
avoir tendance effectivement soit à nous suivre ou sinon à s'affirmer, celle-là où ça devient
intéressant quand les juniors s'affirment ou qui disent moi je préfère de cette façon,
que du coup ils apportent là au prix qu'ils commencent aussi à s'intégrer beaucoup plus dans le
projet et après nous les seniors c'est pareil en fait on m'a beau être trois seniors on s'est déjà
retrouvé même sur des petits points des détails des choses, comment dire, après d'accord ça se prend
la tête et justement c'est ça qui est intéressant et comment vous régliez le truc en fait ?
Au gant de box dans un hexagon ou vous aviez une autre approche ? On a tendance à justement démontrer
un peu du coup pourquoi on aime bien notre méthode on peut être deux contre un, en fait il va se
passer c'est qu'après on va faire valoir plutôt la logique on va dire et puis un peu une part de
bienveillance parce qu'on n'est pas là non plus pour affirmer qu'on est les meilleurs et qu'on pense
différemment parce que c'est forcément mieux mais on essaie justement de trouver un juste milieu
qui permet en fait de plaire à tout le monde donc en général c'est plutôt définir la majorité
et qu'on a un souci et en fait il faut faire participer l'équipe parce qu'en fait c'est un sujet
qui va impacter l'équipe après sur le moteur puisque ça va être le point donc du coup il faut
que l'équipe participe et quelqu'un qui ne veut pas participer ma dernière en fait c'est quelqu'un
qui me dit mot consent si jamais tu ne veux pas participer c'était d'accord avec tout et peu à
peu plus résultat donc après faut pas devenir ce plein dans ce cas là c'est peut-être un peu rude
non non mais c'est je pense que cette notion est assez importante donc finalement ce que tu me
dis c'est que les si je comprends bien il ya quand même une certaine bienveillance dans l'équipe qui
fait que tout le monde joue le jeu si quand on est quand il y a des désaccords vous prenez le temps
d'en parler même si parfois bah quelqu'un n'est pas d'accord mais qu'il y a une certaine majorité
qui se dégage ou une certaine cohérence bah vous partez sur cette règle là et comment ça se
passe si quelqu'un veut modifier par exemple imaginant tu veux tu sens qu'il y a une règle qui
n'est pas pertinente ou tu voudrais rajouter une nouvelle règle c'est quoi le process
là actuellement en fait sur le projet sur lequel je bosse on a je suis confronté du coup à ce type
de cas en fait du coup je suis en train de faire du refactoring donc je modifie mes classes et en
fait on a fixé un ensemble de règues sur la façon de définir les attributs accessoires et
quand les utiliser ou de pas les utiliser sauf que du coup là j'ai utilisé un héritage et du
coup j'ai besoin d'accéder à ces fameuses classes et en fait nos règles contredisent
enfin parce que on avait toujours eu enfin on n'a jamais vraiment utilisé de l'héritage tel quel
en transférant du coup à la fois des contextes des ensembles d'information dans les classes
en forme et tout et en fait ce qui s'est passé c'est que du coup j'entrais directement en conflit
avec une règle qui disait bah en fait quand on définit une classe on fait des initialiseurs on
utilise des des variables avec des arabes à la base en fait ce sont des variables d'instance et on
les définit même en fait on bypass complètement les setters et les quetteurs sauf que pour accéder
en fait à ces variables dans les classes filles en fait il faut les définir comme des attributs
accessoires pour pouvoir y accéder de façon jolie parce que j'ai aussi le côté esthétique à
moi dire l'un du code derrière qui fait que bah du coup je me retrouvais un peu un peu en
contre sens par rapport à tout ce qu'on a défini comme règle et du coup là ce qui s'est passé c'est
qu'en fait on a pendant un délit j'ai dit bah voilà j'ai codé ma classe c'est je suis plutôt
satisfait du résultat sauf que bah je vais envers et contre une bonne partie de nos règles parce
que j'ai utilisé le disait pas terme de l'héritage que j'ai utilisé je me retrouve du coup utilisé
des choses qu'on s'était dit on ne disera jamais ça on va privilégier tel et tel façon de faire
pour que on soit cohérent et harmonisé en termes de groupes et du coup c'est ce qu'on a fait
et en fait c'est en résulter d'une discussion et de se dire effectivement on a plusieurs solutions
il ya plusieurs façons de gérer ça et pour que ce soit à la fois qu'on évite la redondance en
termes de l'inputition du coup bah en fait on a modifié nos règles ok donc en fait c'est passé
par une discussion de groupe et vous avez fait évoluer les choses quoi. Oui oui bah après c'est
dans le principe justement de la daily ou si jamais ça arrive en début de journée après la daily
en fait il faut essayer aussi d'interagir avec les gens en utilisant les outils qui sont à
disposition nous en l'occurrence c'est un slack à partir du moment on a un problème on a un groupe
qui est dédié à notre équipe avec l'APO raclut et bah du coup ce qu'on fait c'est qu'on en discute
et parfois même l'APO peut intervenir même si sur tout ce qui est les standards et les normes du
code ça ne la concerne pas trop mais bon c'est toujours agréable. Ok et c'est quoi les limites
que tu as vu dans l'usage de cet outil en fait ? Disons que je dirais pas qu'il y a vraiment de limites
en soi en fait le problème c'est surtout jusqu'où on peut aller au point de régler à
comment dire à quel point on peut être strict au niveau des rues des règles parce que on peut
se retrouver du coup à fixer des règles de partout et en fait entrer complètement à l'encontre de ce
qu'on pourrait faire au niveau du code notamment quand on récupère un projet négatif un projet
qui a été monté par une autre équipe qu'on se retrouve du coup avec ce projet qui nous arrive
dans les mains et qu'on veut fixer des règles en fait au début on va les fixer mais à partir
du moment on va vouloir commencer à modifier les fichiers et exécuter le lintern. Tu veux fixer
les règles ou tu veux fixer les problèmes ? On va fixer les règles mais on va les fixer à notre
ça c'est souvent le souci et parfois en fait il existe même moins dans mon équipe en fait on va
différents profils. On a un profil qui est monsieur Ronchon que je salue au passage qui est du
coup quelqu'un qui est très carré très strict et très critique du coup il va nous apporter
justement un peu ce côté là de mettre ceinture brotel et après le travail aussi des autres
équipes c'est aussi d'assouplir cela pour trouver un juste milieu et donc l'idée c'est justement
de vraiment travailler pour peut-être partir d'un schéma un peu brut et venir assouplir
un peu les angles on va dire sur certains points. Le problème c'est qu'il existe aussi des milliers
de règles que l'on peut fixer et c'est un travail qu'on peut pas faire en acclâtement de doigts ou
à part en utilisant des fichiers qui sont souvent à nous pour nous on a commencé à prendre le
standard de notre framework de Rails et on a pris celui qui avait la même version de Rails que nous
et on l'a intégré dedans et on s'est dit on va partir là, ça va être notre base de travail et
puis au fur et à mesure on va venir l'enrichir, ajouter des règles qu'on trouve plus ou moins
justes, se baser aussi sur des recommandations qui peuvent venir de notre vallité technologique qui fait
que du coup on va se dire bah tiens j'ai vu tel article ils expliquent pourquoi j'ai mis le privilégier
telle notation ou tel format et en fait du coup si l'équipe est d'accord on les intègre et on fait
évoluer notre fichier pour venir le développer après du coup effectivement la limite c'est le jour
où on se met à faire du refactoring à modifier un peu tout ça pour améliorer et optimiser
ou altérer, on risque de se retrouver effectivement avec des règles qui rentrent directement en
couflis et la question c'est pas de se dire est ce qu'on a mal fait depuis le début où toute
norelle est son caduc non c'est là parce qu'on les a définis ensemble ça marchait très bien
c'est juste qu'aujourd'hui le projet évolue il change donc du coup les règles doivent changer
il faut pas que ça change non plus tous les jours mais quand on a des changements notamment
au niveau du design et l'applicatif du coup il faut aussi adapter un peu les règles surtout quand
on parle sur des nouveaux formats qu'on n'utilisait pas. Bah écoute merci pour ce retour d'expérience
jérémy si je te propose qu'on arrête là si les auditeurs veulent en savoir plus sur ce que tu
fais est ce que tu publie est ce que tu veux parler de ce que fait ta boîte ? Oui bah oui du coup
après pour entreprise donc c'est efi.fr, e2efi.gr.fr, moi du coup je suis sur twitter mais pas très
actif donc plutôt sur github mais toujours sous le même login donc c'est elentras,
e-l-e-n-t-r-a-s et bah du coup je l'ai toujours en plaisir d'échanger sur la tech. Eh bah écoute
merci beaucoup jérémy. Je te remercie aussi. Quand t'as toi sur auditeurs bah écoute j'espère
que t'as apprécié ce podcast j'espère que tu que ça t'a aidé à réfléchir peut-être que ça
t'a donné envie de mettre en place quelque chose ou de faire évoluer ta pratique notamment autour
de cette question de comment est-ce qu'on définit un standard de code comment est-ce qu'on le fait
respecter et je pense que c'est un épisode qui se prête particulièrement bien et n'écoute partagé
tu as pas tes collègues développeur avec un petit truc à manger ça c'est un type qui marche toujours
tu vois tu mets un gâteau des bonbons un petit peu de sucre tu l'es fait écouter pendant un quart d'heure
cet épisode et après vous en débattez vous en débattez pendant encore un quart d'heure ça te fait
un truc qui durerait une petite demi heure ça c'est très bien pour le café et en général ça donne
lieu à de très bonnes discussions je termine ici je te dis à bientôt tcho