Merci de laisser ce code dans l'état dans lequel vous aimeriez le trouver

Bonjour à tous J'ai pas besoin de le redire voilà je m'appelle Cédric.

Je suis CTO chez Novaway, une agence lyonnaise.

Mon premier contact avec avec la qualité logicielle c'était il y a une bonne dizaine d'années maintenant c'était avec cette citation : "Code toujours comme si la personne qui va maintenir ton code est un violent psychopathe qui sait où tu habites" ça m'a bien fait rire, je pense que c'est pour ça que dix ans après je m'en souviens.

Ça m'a moins fait rire l'année dernière, parce qu'en fait on m'a dit "Tu vas refiler le code sur lequel tu bosses ... à JP".

(J'avais hâte de la mettre sur un écran de 6 mètres de haut) Donc voilà je me suis dit "Là, j'ai un peu peur pour ma vie.

j'ai pas trop envie de me prendre un coup de hache donc j'ai intérêt à lui filer du bon code à JP "Qu'est ce que c'est que du bon code ?" finalement Et bien le bon code, ça dépend de qui on est et d'où on se place, par exemple pour certains utilisateurs ou certaines utilisatrices, ça va être du code qui rend plus productif ou plus productive pour d'autres, on est en plein dedans avec l'actualité, ça va être du code qui respecte la vie privée.

Il y a aussi des gens pour qui du bon code, c'est du code qui est accessible.

Après on peut se placer d'un point de vue plus technique et dire que le bon code c'est du code S.O.L.I.D.

Ou alors si on se place d'un point de vue Product Owner ou d'un point de vue de CEO ça peut être du code qui coûte peu ou, si on est un bon CEO du code qui rapporte beaucoup, il y a une petite nuance entre les deux.

Bref, il y a quand même beaucoup de façons de voir ce que c'est que du bon code donc revenons à mon histoire de hache.

Moi je me suis dit que ce qui m'intéresse dans ce cas là c'est finalement la "developer experience" c'est à dire d'avoir du code qui permet de travailler dans des conditions efficaces et de la meilleure façon possible en étant le plus confortable avec le code possible.

Alors avant de rentrer dans le vif du sujet il y a une question à se poser c'est "qui va maintenir le code ?" donc déjà on a vu que ça pouvait être un membre de l'équipe (avec ou sans hache).

Ça peux être plein d'autres gens. Par exemple : une équipe de TMA dans une SSII qui va sous-traiter ça à ses équipes en Inde où ça ne leur coûtera pas cher.

Nous dans le futur en fait, dans six mois, dans un an, dans deux ans ...

Donc voilà, ce que je vais dire aujourd'hui, si vous ne le faites pas pour les autres faites le au moins pour vous.

Donc pour parler de maintenance logicielle je voulais parler un peu de criminologie d'abord avec ce qu'on appelle les fenêtres cassées.

En criminologie, la théorie des fenêtres cassées, c'est de dire que dans un bâtiment en bon état, si on casse une fenêtre et qu'on ne vient pas la réparer, le bâtiment va se dégrader de plus en plus vite de façon assez exponentielle.

En fait l'idée c'est de se dire ben voilà la première fenêtre va casser, personne ne va la réparer, on va en casser une deuxième, personne ne va trop s'inquiéter il y en a déjà une de cassée donc pourquoi réparer celle ci, et de fil en aiguille les choses vont empirer et empirer et ça va s'accumuler et dans le code finalement c'est un peu pareil on va prendre une fois un raccourci on va le faire pour de bonnes ou de mauvaises raisons il y a de bonnes raisons de prendre un raccourci dans le code mais si derrière on ne vient pas le corriger eh ben on va avoir un problème parce que quelqu'un d'autre ou soit même va dire bah tiens il y a ce raccourci qui a été pris à cet endroit là je vais pouvoir le prendre moi aussi et puis de fil en aiguille ça va continuer ça va s'entasser et au final ça va créer de la dette technique.

Donc, voilà les fenêtres cassées créent de la dette technique comme j'ai dit on peut avoir de bonnes ou de mauvaises raisons de créer de la dette technique mais dans tous les cas il faut la rembourser et la dette technique en fait il y a plusieurs façon de résorber cette dette technique et pour moi le pire ennemi de la dette technique c'est la communication.

Si vous voulez un peu résorber la dette technique moi ce que je vous conseille c'est vraiment de travailler sur la communication.

Alors j'ai distingué deux types de communications : la communication entre les devs et la communication avec le reste, je n'ai pas trouvé de pas trouvé de meilleure terminologie donc ça sera "avec le reste".

Donc la question c'est comment on fait une bonne communication en fait dans ces deux catégories.

La première étape pour la communication entre devs c'est d'écrire du code humain j'vais reprendre une citation celle de Martin Fowler qui est un des papas du manifeste agile qui disait "n'importe quel imbécile peut écrire du code que les machines comprennent les bons développeurs et les bonnes développeuses écrivent du code que les humains comprennent".

Dans notre métier on passe en moyenne 10 fois plus de temps à lire du code qu'à en écrire Donc c'est important qu'on écrive du code qui soit lisible.

Alors comment on fait pour écrire du code du code que les humains comprennent ? Pour ça faut comprendre un concept qui s'appelle la charge cognitive.

La charge cognitive qu'est ce que c'est ? En gros pour faire une analogie c'est un peu les barrettes de RAM du cerveau, en fait c'est la capacité de mémoire qu'on a dans le cerveau. La seule différence c'est que quand on n'en a pas assez on ne peut pas la commander sur LDLC.

Du coup, non j'ai pas été payé pour celle là.

Du coup il va falloir l'optimiser cette charge cognitive.

Et du coup, je vais prendre un exemple il y en a peut-être certains d'entre vous qui ont des enfants en bas âge.

Aujourd'hui dans l'éducation on parle beaucoup dans l'éducation des jeunes enfants de charge cognitive, notamment avec avec les rituels. Moi typiquement j'ai une petite de 2 ans le soir après le repas je la pose par terre elle est en pilote automatique elle fait tout toute seule, elle sait exactement tout faire et c'est super important les rituels pour les enfants d'ailleurs il y en a souvent qui se frustrent parce qu'on n'a pas suivi leurs rituels c'est tout simplement parce que leur cerveau est fait pour apprendre du coup tout ce qui ne leur sert pas à apprendre ce qui est tout ce qui est trivial qu'on fait tous les jours eh ben c'est devenu automatique dans leur cerveau justement pour pouvoir apprendre.

Dans le développement on peut avoir la même chose.

C'est à dire qu'en fait on peut essayer d'entraîner notre pilote automatique pour pouvoir se focaliser sur ce qui est essentiel et ce qui est essentiel dans le développement c'est l'algorithmie.

Donc il y a plusieurs façon de libérer un peu, d'optimiser cette charge cognitive la première elle est assez évidente c'est l'utilisation de standards.

Utiliser les standards c'est écrire du code qui soit familier, et du code qui est familier c'est du code dans lequel on navigue beaucoup plus facilement, plus facilement de façon automatique donc voilà on a parlé pas mal pendant ces deux jours du PHP-FIG qui travaille entre autres sur les standards et du coup on a maintenant des outils qui permettent de façon assez simple à la fois de corriger ses standards et même par exemple si vous prenez la dernière ligne on met ça dans un serveur d'intégration continue et hop on a une alerte "attention tu respectes pas les standards".

Respecter les standards aujourd'hui c'est quelque chose qui est relativement simple même les IDE le font automatiquement ça corrige votre code limite à la sauvegarde de la sauvegarde du fichier.

Il y a d'autres façons encore de limiter cette charge cognitive c'est avec les design patterns, qui est aussi une forme de standards finalement. Les design patterns dans la philosophie l'idée c'est quoi c'est de se dire "à un même problème j'apporte la même solution" en fait il ya des problèmes qu'on rencontre tous les jours tout le monde les a déjà rencontré et beaucoup de gens les ont rencontrés avant nous donc on a une solution qui est commune qui est connue autant l'utiliser on va pas réinventer la roue à chaque fois.

Et du coup en se familiarisant en utilisant beaucoup ces design patterns on se retrouve à libérer de la charge cognitive parce que ça rentre, ça devient automatique Pour ceux qui ne sont pas trop encore dans les design patterns, moi je recommande ce bouquin.

Bon c'est du java je suis désolé, mais je trouve que c'est assez bien expliquée, il y a beaucoup d'analogies avec des cas réels; et du coup moi j'aime beaucoup les analogies donc donc voilà si jamais vous n'êtes pas trop dans les design patterns je vous recommande ce bouquin.

Pour limiter la charge cognitive aussi on peut faire du code qui parle comme nous.

Alors qu'est ce que j'entends par du code qui parle comme nous ? En français on a une grammaire, on a une conjugaison.

Dans le code c'est pareil on a des syntaxes tout ça.

Pour autant on peut on peut faire des phrases qui ont une bonne grammaire qui ont une bonne conjugaison et que personne ne comprend parce ce qu'elles sont sont pas claires.

Dans le code - ça c'est ce que j'appelle le doctrine generated... le doctrine driven design - voilà c'est du code typiquement pour un article de blog on a une fonction "setState" qui attend un paramètre une chaîne de caractères et on a une fonction "getState" qui retourne une chaîne de caractères.

Ce que j'aime beaucoup faire moi, on le voit beaucoup dans les revues que je fais, c'est en fait de transposer le code en français là typiquement si je veux publier mon article de blog, la phrase en français que je vais donner comme consigne à mon blog finalement ça va dire définit l'état du blog à "publié".

Finalement si on veut parler un peu plus français ce serait : "publie".

Les deux sont corrects d'un point de vue grammaire et d'un point de vue conjugaison mais c'est quand même un petit peu plus clair si tu dis "publie" ou "dit moi si tu es publié".

Donc voilà donc écrire du code qui parle comme nous bah pareil ça ça libère de la charge cognitive parce que on va pas réfléchir trois heures à comprendre le code, il est relativement naturel dans sa lecture.

Dernier point que je vais aborder sur la charge cognitive c'est la complexité cyclomatique. Qu'est ce que c'est la complicité cyclomatique ? Déjà c'est un mot assez compliqué donc ça fait très intelligent quand vous l'utilisez dans une revue de code.

Et donc la vraie définition de la complicité cyclomatique c'est en fait le nombre de chemins linéairement indépendants que peut prendre un algorithme, en gros pour simplifier si vous faites "if" avec une condition très simple vous augmentez votre complexité cyclomatique de 1 c'est à dire qu'avant vous aviez un chemin maintenant vous avez deux chemins : le cas où je passe dans le "if" et le cas où je ne passe pas dans le "if".

Donc voilà la complicité cyclomatique c'est finalement assez simple dans le dans l'explication mais le mot est très compliqué donc c'est cool ça fait intelligent et donc cette complexité cyclomatique elle est liée à la charge cognitive parce que du coup à chaque fois qu'on va rajouter des chemins il va falloir retenir ces chemins quand on va débugger le code ou quand on va essayer de l'améliorer.

Donc voilà donc essayer de limiter la complexité cyclomatique du code c'est finalement rendre le code plus maintenable Il y a un outil (qui est français d'ailleurs (cocorico)) qui s'appelle phpMetrics et qui permet d'afficher différents facteurs de maintenance notamment ces graphiques là.

Donc la taille correspond à la complexité cyclomatique du fichier et la couleur correspond au niveau de maintenabilité calculé avec avec différentes metrics que je vais pas lister aujourd'hui mais qui sont assez exhaustives et du coup on se rend quand même compte qu'il y a une bonne corrélation là c'est deux projets différents de taille assez différente mais dans tous les cas on a une corrélation entre la complexité cyclomatique d'un fichier et la maintenabilité derrière. C'est jamais les gros disques qui sont qui sont les plus verts.

Donc voilà ça c'était pour le point écrire du code humain.

Le deuxième point qui fâche un petit peu plus c'est la documentation. En général dans le développement non 'aime pas trop la documentation sauf certains Donc voilà, la documentation c'est important je pense que si vous étiez là hier dans la bonne salle vous le savez.

Du coup le premier le point d'entrée de la documentation c'est le fichier README. Typiquement maintenant surtout les tous les outils de contrôle de code source que ce soit Github, Gitlab, Bitbucket ...

quand vous arrivez sur un projet, sur librairie vous tombez sur le fichier readme en fait c'est vraiment le l'idée en fait de ce ficher là c'est de dire voilà quelles sont les clefs pour démarrer sur le projet.

Ça n'a pas besoin en fait d'être une documentation exhaustive de tout ce que fait le projet de tout ce que fait la librairie, mais ça doit donner les points d'entrée normalement si on suit bien tout ce qui est expliqué dans le README à la fin on est opérationnel on est prêt à travailler on est prêt à être productif.

Donc voilà, essayez de faire des README qui permettent aux gens d'être tout de suite productif sur les projets sur lesquels vous travaillez.

Alors après voilà ça c'est le README c'est le point d'entrée Ce qui fâche le plus c'est d'écrire la suite c'est à dire des gros pavés de documentation parce que voilà on va se dire ouais mais là ça va pas être maintenu il va falloir le réécrire à chaque fois que je mets de nouvelles fonctions tout ça aujourd'hui on a ce qu'on appelle la documentation vivante donc la documentation vivante comme son nom l'indique c'est de la documentation qui va vivre avec le code il y a plusieurs catégories de documentation vivante la première c'est, enfin la première il n'y a pas d'ordre, mais la première je vais vous présenter aujourd'hui c'est la documentation auto-invalidée, donc la documentation auto-invalidée le cas qu'on rencontre le plus souvent c'est les tests. Là j'ai pris phpSpec mais ça marche avec n'importe quel framework de test l'idée c'est de dire voilà là je lance ma suite de tests je vérifie que mon mon post peut être publié ok il peut être publié, le jour où je fais une modification dans le code et que du coup mon test devient rouge je sais que ma documentation n'est plus valide c'est à dire que mon test ne documente plus mon code.

Donc ça c'est une catégorie de documentation qu'on appelle la documentation auto-invalidée.

Il y a un autre type de documentation c'est la documentation auto-générée. Donc là c'est royal elle va tout faire tout seul.

C'est pas aussi facile mais l'idée c'est de dire voilà la documentation va se générer de façon automatique.

Alors il y a plein d'outils celui que je vais vous présenter aujourd'hui c'est Pickles.

Je vous en parle rapidement : Pickles en fait c'est simple vous lui filez des scénarios, des features Gherkin comme ce qu'on utilise dans Behat et lui va générer un petit site web avec du HTML assez dynamique où vous allez avoir voilà un menu, vous allez avoir une fonction de recherche, et tout ça va se faire tout seul donc si en plus vos features Gherkin sont bien écrites et qu'elles expliquent bien le métier en fait du le métier que représente le code et bien derrière vous allez presque avoir finalement une documentation un manuel utilisateur de votre code et généré en HTML et utilisable par n'importe qui même de non-technique.

le dernier mode de documentation vivante dont je vais parler aujourd'hui c'est la documentation vivante historique : c'est-à-dire finalement ce qu'on trouve dans les contrôleurs de code source.

Je prends un petit scénario donc mettons que les deux types de documentation j'ai cités précédemment ne soient pas disponibles.

On est là, on travaille sur un bout de code, on rencontre un algo qu'on comprend pas très bien, on n'a pas les tests on n'a pas la documentation écrite ou alors ça l'explique mal, ça ne correspond pas à ce bout de code.

Et du coup on se dit je vais aller voir dans le controleur de code source essayer de trouver le commit qui correspond à ça, il y aura peut-être des explications sur le message de commit et là on tombe sur ça : "fixes".

C'est mon préféré celui-là parce, qu'en plus "fixes" il a cette particularité c'est qu'il est au pluriel c'est à dire que potentiellement il va y avoir des fichiers des modifications dans ce commit là qui ne vont pas du tout m'intéresser.

Donc voilà, les messages de commit c'est quelque chose qui est super important, c'est de la documentation donc c'est quelque chose auquel il faut apporter quand même un minimum d'attention.

Donc, faites pas ce genre de truc. Il y a un petit point sur lequel je voulais insister aussi souvent enfin maintenant je pense qu'il y a plus beaucoup de monde qui fait ce genre de messages de commit mais souvent on oublie.

Mais même des fois en s'appliquant on oublie une chose, c'est le contexte en fait c'est à dire que souvent les messages de commit quand on les lit dans le contexte de la modification c'est à dire ben peut-être le lendemain ou enfin quand on l'écrit surtout on l'écrit en se disant ben voila je suis dans telle modifications ça ça correspond à ça dans la modification on oublie que six mois après il va manquer la moitié des informations on va pas du tout comprendre où ça va être parce que on sera plus vraiment dans le contexte donc il y a aussi cette information-là à garder quand on fait un commit c'est fournir le contexte.

Petit autre conseil que je donnerais aussi c'est essayer d'expliquer pourquoi en fait parce que quand on va aller chercher à une information dans un message de commit, souvent va vouloir savoir pourquoi si vous expliquez exactement ce qui a été fait on peut lire le code c'est bon on sait ce qui a été fait en c'est ce qui a été modifié, on le voit.

Par contre, on veut savoir souvent c'est pourquoi.

Dernière petite astuce, j'ai l'impression qui n'est pas très connu c'est que ça peut être multi-lignes en fait un message de commit et du coup la première ligne va correspondre vraiment aux messages et toute la suite ça va être en fait des commentaires une description finalement du commit. Donc même si vous n'avez pas envie de faire un message de commit qui soit hyper long parce que ça va pas s'afficher va y avoir trois petits points machin dites vous que derrière vous pouvez apporter pas mal d'informations dans cette description est que le jour où quelqu'un ira voir ce commit en particulier il aura plein de contexte dans cette partie là.

Donc voilà, ça c'était sur la partie documentation ce dont je voulais parler aujourd'hui et puis le dernier point dans la communication entre développeurs, c'est de faire des revues.

En revue j'entends plein de choses, enfin pour moi il y a revue de code, il y a pair programming, le mob programming aussi hein plus on est de fous plus on rit ! Toutes ces choses là, en fait l'idée derrière l'idée sous-jacente c'est de se dire qu'il n'y ai pas une seule personne qui ai travaillé sur un bout de code et que ce bout de code et bien finalement il soit commun à plusieurs personnes avant de partir en prod et du coup ça a plusieurs avantages si on ne regarde pas bien si on regarde un peu avec des œillères on va se dire ouais c'est de la perte de productivité j'ai deux personnes qui travaillent sur la même chose alors que finalement une seule personne ça suffirait mais derrière qu'est ce qu'on a ? Du coup on a déjà de la diffusion de responsabilité c'est à dire qu'on a plus une seule personne qui porte sur ses épaules la responsabilité d'un bout de code.

On a de la diffusion de connaissances puisque du coup tous ceux qui ont lu le code sans forcément toujours rentrer dans les détails ont au moins un peu de connaissance de ce qui a été fait et puis du coup on a de la qualité qui est augmentée alors j'ai pas les nombres sous la main mais il y a des metrics qui ont montré qui ont montré que la revue de code c'était aussi bon sinon mieux que les tests pour détecter des bugs ou des failles de sécurité.

Si ça vous intéresse je peux essayer de vous trouvez ça là je les ai pas ici.

Donc voilà, donc la revue de code c'est pas c'est pas de la perte de temps, nous ça fait plusieurs années maintenant qu'on a ça à Novaway c'est vraiment le truc sur lequel moi je reviendrai pas, c'est la partie la plus importante de notre process qualité.

Donc voilà, ça c'est pour la partie communication entre développeurs : écrire du code humain, le documenter, le documenter en mode "code augmenté" pas forcément en texte brut et faire des revues.

L'autre question qui nous intéresse c'est comment on communique avec le reste.

Pour bien communiquer en fait avec les personnes qui sont pas techniques ce qu'il faut comprendre c'est le concept de feedback loop.

Aujourd'hui si on regarde il y a pas mal de tendances en fait dans le développement logiciel que ce soit le scrum que se soit le lean start up, ils ont tous en fait une même directive c'est de réduire au maximum la feedback loop pour qu'elle soit le plus petit possible et qu'on ai des retours le plus rapidement possible.

Donc ça vaut pour des retours sur un produit en fait ça vaut aussi pour la communication dans une équipe ou la communication avec un client. C'est à dire que si on attend on attend un mois ou même même moins pour remonter certaines informations, des fois l'information ne sera plus pertinente. Ce qui fait la pertinence en fait d'une information c'est aussi le moment à laquelle elle est délivrée, et du coup plus on réduit cette feedback loop plus on a de possibilités de donner une information qui soit pertinente au bon moment.

Donc voilà essayez dans toutes les communications de réduire au maximum la feedback loop.

Donc ça peut se faire typiquement si on utilise les principes agile, Ça se fait par exemple avec des meetings réguliers des meetings quotidiens, ça peut se faire avec des rétrospectives à la fin d'un sprint. Mais voilà l'idée c'est vraiment de se dire communiquez le plus souvent possible ne pas attendre trop longtemps pour remonter un problème, une information.

Alors, il y a peut-être des managers dans la salle, moi quand j'étais dans mon précédent emploi tous les managers avec lesquels j'ai travaillé avaient tous cette politique de la porte ouverte.

Cette politique qui dit tu peux venir dans mon bureau il n'y a pas de problème si tu vois un truc qui va pas bien tu viens me le dire moi ma porte est toujours ouverte.

Moi à l'époque j'étais junior, j'avais moins de deux ans d'expérience, je suis introverti par nature, je suis jamais allé les voir, j'avais plein de choses à dire, je ne suis jamais allé les voir.

Je pense que je suis pas le seul. Pour moi la politique de la porte ouverte en fait elle est assez néfaste parce que en gros c'est une décharge de responsabilité en fait du manager vers les équipes qui sont managées.

Alors ça veut pas dire que les équipes qui sont managées ont aucune responsabilité dans la communication, mais c'est pas c'est pas forcément à eux de détecter ce qui va pas dans les fonctionnements et c'est pas forcément à eux de mettre les choses en place pour les régler.

Donc voilà c'est une politique que je trouve assez néfaste.

Personnellement j'aimerais pas un jour me retrouver à la fin d'une situation de crise à dire mais tu aurais dû venir me voir moi pour moi si je dis ça à quelqu'un c'est un échec en tant que manager c'est à moi d'aller voir d'aller rencontrer les gens et d'aller savoir ce qui se passe de bien ou de pas bien du coup assez récemment j'ai mis en place c'est pas moi qui l'inventé mais c'est une politique de 1-on-1 l'idée c'est de faire en fait des entretiens individuels avec l'équipe très régulièrement enfin disons que je fais pas encore assez régulièrement j'aimerais le faire encore plus régulièrement pour le moment j'essaie de le faire au moins une fois par mois mais j'aimerais bien augmenter encore la fréquence.

Voilà l'idée c'est vraiment de faire des points alors c'est pas c'est pas des points projet faut vraiment pas le voir comme un point projet il y a des outils il y a des process pour suivre l'avancement des projets c'est vraiment pour avoir des points d'equipe savoir un peu comment ça se passe on peut faire plein de choses, on peut on peut parler carrière on peut parler conseil on peut parler perso il n'y a pas de problème l'idée c'est vraiment d'avoir de ce ressenti en fait des équipes savoir comment est l'équipe et pas attendre en fait l'entretien annuel pour savoir ce qui va ou ce qui va pas. Parce qu'entre deux entretiens individuels quelqu'un qui est pas bien il peut partir et ce n'est pas le but, le but c'est que les gens se sentent bien dans leur boulot et du coup d'essayer de repérer au plus rapidement les gens qui ne se sentent pas bien.

ou quand je dis se sentent pas bien ça peut être même des choses qui sont anodines parce que même les choses anodines elles peuvent par effet boule de neige empirer et du coup si on l'a pas repéré assez rapidement on peut pas mettre en mesure les actions correctives derrière.

Donc voilà, les politiques de 1-on-1 pour détecter les problèmes, pour faciliter la communication c'est quelque chose de très important.

Donc voilà, la communication "avec le reste" : réduire la feedback loop, éviter d'avoir une politique de "porte ouverte", parce que ça ne marche pas.

Et du coup essayer d'avoir par exemple des 1-on-1. Il y a peut-être d'autres méthodes que je connais pas.

Pour moi c'est une méthode que je trouve assez pertinente.

Voilà c'est l'ensemble de mes points pour améliorer la communication.

Je suis allé un peu vite, du coup je finirai donc juste sur une citation d'une de mes idoles depuis maintenant bien longtemps : "le talent remporte des matches mais c'est le travail d'équipe et l'intelligence qui remportent des championnats".

Merci à vous.

- Du coup on a du temps pour les questions même s'ils ont été plus vite que nous .

Qui a des questions ? Je ne vois pas là ... ha ... pardon - Merci déjà pour la présentation c'était très intéressant J'avais une question concernant la fréquence des revues de code.

Quelle est selon toi la meilleure fréquence si c'est quotidien, si c'est hebdomadaire, si c'est sur un exemple d'un gros contrôleur etc ou aussi il faut à chaque contrôleur qu'on effectue chaque fonction refaire une review à chaque fois.

- Alors ça va être à chaque fois, en fait si tu prends aujourd'hui tous les grands outils de contrôle de code source que ce soit Github, Gitlab, Bitbucket ...

ils fonctionnent tout sur un système ... bon ils appellent pas ça pareil des fois c'est merge request des fois c'est pull request mais l'idée c'est de dire voilà je développe une fonctionnalité et je vais la réintégrer dans la branche dans le tronc commun et du coup à chaque fois que t'as cette réintégration dans le tronc commun tu dois passer par par une revue de code pour te dire ok c'est ok pour repasser dans le tronc commun ou non il y a ça ça ça qui va pas donc ça passe pas dans le tronc commun donc après la bonne pratique c'est d'essayer de faire des faire du travail sur des branches qui soit le plus petit possible parce qu'il y a un dicton qui dit une revue de code avec 10 lignes de code on va y passer une heure et une revue de code avec 100 lignes de code on va y passer deux minutes.

En fait l'idée c'est de se dire les gens seront plus attentifs à ce que tu as fait si c'est assez atomique alors que si tu balances un gros truc les gens vont lire en diagonale et au final ça va ça va potentiellement passer avec des problèmes.

Voilà mais l'idée c'est vraiment de se dire dès qu'il y a quelque chose qui réintègre le tronc commun c'est revu, sa passe pas si c'est pas revu.

- On a encore le temps pour une question - Bonjour alors, merci beaucoup pour la présentation.

Moi la question c'était sur le 1-on-1, j'en ai fait à une période mais il est vrai qu'il y a certaines choses même en 1-to-1 que je ne disais pas parce que j'étais potentiellement intimidé ou je voulais pas que ça me retombe dessus derrière ou autre du coup qu'est ce que tu conseillerai comme comme dialogue comme message pour mettre la personne en confiance et qu'elle soit honnête envers toi même ? - Alors j'avoue que j'ai pas de recette magique, après ça peut paraître bateau mais mais l'idée c'est d'être d'être intéressé de façon de façon sincère en fait à la personne c'est pas de dire je fais ce 1-on-1 parce que voilà c'est le process de faire le 1-on-1 ça me fait chier d'être là mais je le fais avec cette personne là. Non c'est d'être sincèrement intéressé par la personne avec qui tu travailles après moi personnellement je pense que si t'es pas intéressé pour les personnes avec qui tu travailles tu n'as pas ta place en tant que manager. Manager c'est pas c'est pas un échelon en fait ce n'est pas une évolution du développeur c'est un autre métier et si t'es pas intéressé par l'humain par les gens avec qui tu travailles c'est pas pour toi le boulot de manager donc voilà d'être sincèrement intéressé par les gens avec qui tu travailles pour moi c'est la meilleure façon de les mettre en confiance je dis pas que ça marche à chaque fois mais au moins tu auras les démarches pour le faire de façon naturelle.