J'ai rejoint ma nouvelle équipe il y a 6 mois, avec une appréhension. Comment allais-je vivre les revues de code par des collègues que je ne connais pas encore ? Incompréhensions, malentendus : la communication écrite rend cet exercice très délicat. Vous avez été blessé-e par un commentaire ? Etait-il vraiment mal intentionné ? Vous avez blessé quelqu'un sans le vouloir, à cause d'une tournure maladroite ?
Dans mon équipe, j'ai découvert un cadre qui m'a permis de me sentir bien accueillie dès mon arrivée. En adoptant une posture et une convention bien adaptée, on peut largement diminuer le risque de mal se comprendre. Non seulement on communique mieux, mais on améliore la qualité globale du projet.
Vous n'aurez plus aucune raison de souffrir !
_ Bonjour. Merci pour cette présentation très sympathique. Merci l'AFUP. Je suis honorée d'être ici, devant vous. Ça vous est déjà arrivé de vous sentir un peu blessé ou fixé sur un commentaire sur votre code ? Ça m'est déjà arrivé. Je voudrais vous parler de ça aujourd'hui. Je m'appelle Anne-Laure, je suis développeuse back chez Bedrock. Je suis adhérente de l'AFUP et je fais partie de ceux qui organisent MiXit. J'aime le cinéma de genre, et les fanzines et les BD. Je viens de Croix-Rousse. C'est mieux que Lyon ! Quand on parle de revue de code, on parle de quoi ? On fait de la revue de code tout le temps, en réunion technique, quand on parle d'implémentation de solutions techniques, quand on revoit l'architecture de nos projets et on en fait aussi bien la revue du delta du code. C'est quand on regarde entre pairs le code que l'on propose à rajouter au tronc commun. On a l'habitude de faire ça via des outils comme Github.com. On a un commentaire en dessous pour discuter avec la personne qui a soumis le code, en lui suggérant des choses. Ici, on est sur Github. On fait des projets. Il y a d'autres outils, comme Gitlab. C'est le même concept. On voit la différence du code proposé. On peut mettre aussi des commentaires. Il y a plein de tirs. Il y a quelques mois, je travaillais chez Elao, qui est une agence Web à Lyon, où travaillent 12-15 développeurs. On était maximum 2-3 à travailler par projet. J'ai rejoint Bedrock. Il y a plus de 80 développeurs et développeuses. Rien que dans mon équipe, on est 9. L'équation changeait pas mal. Quand je proposais mon code à la review chez Elao, j'étais plutôt tranquille, on se connaissait bien. Quand les commentaires prenaient plus de deux ou trois lignes, on allait se voir, se parler. C'était plutôt tranquille.
Avant d'arriver chez Bedrock, je dois avouer que j'étais un peu anxieuse. Je me demandais comment ça allait se passer. Je savais que toutes les personnes de la team faisaient de la review et je me demandais quelle paire d'yeux allait se poser sur mon code. En plus, j'ai appris que les reviews étaient en anglais. Ça pouvait rajouter des risques de quiproquos ou de malentendus. Je vous spoile. Tout se passe très bien. Les reviews se passent très bien. Mon équipe utilise un standard qui est celui du conventional comment. Cela a beaucoup facilité mon intégration. Revenons aux sources. On fait une revue de code pour améliorer la qualité globale du code. On va aussi améliorer la lisibilité. On va chercher à appliquer les standards de l'équipe. On va chercher aussi à détecter les bugs. On améliore aussi la collaboration et la communication avec l'équipe. On va former des personnes, on va se former nous-mêmes en recevant des commentaires. Et on va partager la responsabilité en approuvant des pool request, tout le monde va partager la responsabilité du code qui va être poussé dans le tronc commun. On peut soulager les humains pour tout ce qui n'a pas de valeur ajoutée à être écrit par un humain. Je trouve ça plus agréable de recevoir un commentaire de la part d'un robot qui me dit que c'est bof, plutôt que de la part d'un humain qui a pris le temps de voir ça et de me le dire car je ne l'ai pas vu en vérifiant mes fichiers. Vous allez me dire qu'on a aucune raison de souffrir. On se pose des questions, on s'aide mutuellement. Il ne devrait pas y avoir de souci. Mais comme moi, vous savez, parfois, on peut manquer d'empathie. On peut se sentir plus compétent en critiquant les autres via des commentaires. On peut aussi vouloir se rassurer en se montrant plus qualifié. Et on peut être habitué aussi à la culture de la compétition entre nous.
Parfois, on souffre. Les commentaires peuvent être laborieux à lire ou à écrire. Il peut y avoir des maladresses ou des incompréhensions qui nous font perdre beaucoup de temps sur une feature alors que ça n'aurait pas lieu d'être. Et on peut avoir des retours cruciaux, noyés dans d'autres tours en ne sachant plus quelle est la priorité. Est-ce qu'on peut faire mieux ? Bien sûr qu'on peut faire mieux. Je vous ai parlé du standard des conventional comments.
Je voulais d'abord vous parler d'une posture qui est nécessaire et qui est un prérequis. Avant de formater des commentaires, il faut chercher à se mettre dans une bonne posture pour les recevoir et pour les écrire. Je voudrais vous parler de l'Egoless programming. Je sais ce qui vous traverse toute l'esprit. On parle bien de l'ego, le sujet pensant, le Moi. L'Egoless programming, c'est chercher à avoir un ego qui a moins d'impact sur nos interactions et nos comportements avec eux tous nos collègues. Vous allez me dire : sacré programme. En 1971, Monsieur Weinberg a écrit un livre où il propose cette posture, qui nous pousse à minimiser les facteurs personnels dans l'objectif d'améliorer la qualité globale du code, tout ça en émettant des critiques respectueuses, collégiales, où on essaye de mettre les sentiments de côté. Il y a une dizaine de commandements. J'en ai pris certains, parmi les plus intéressants. J'ai gardé la langue originale pour le commandement. "Comprenez et acceptez que vous faites des erreurs." Essayer de l'accepter pour soi, c'est déjà avoir plus d'empathie envers soi-même. C'est plus facile d'accepter les erreurs de la part des autres au moment où l'on fait nous-mêmes des revues de code. "Vous n'êtes pas votre code." Quand vous repassez dessus 6 mois plus tard, vous dites que vous pourriez faire mieux parce qu'entre-temps, vous avez appris. Le code appartient à l'équipe ou à l'organisation pour laquelle vous travaillez. L'objectif est d'améliorer ce code. Toutes les critiques qui sont faites à son encontre ne vous concernent pas, mais c'est pour améliorer le code et pour diminuer tous les risques de bugs.
Egoless ne signifie pas ne pas avoir d'ego. On peut aussi accepter la défaite. Si on a une solution technique, on ne bonne idée d'implémentation que l'on veut pousser, si ce n'est pas le choix retenu, il faut aussi essayer de l'accepter et de continuer à travailler dans la bonne humeur. Ce commandant sera un peu guise de conclusion : "On critique le code plutôt que les personnes. On va être sympa avec le codeur mais pas avec le code." Qu'est-ce qu'on peut retenir ? On va chercher à ne pas laisser notre ego nous contrôler. En groupe, on produira le plus de qualité possible. Et on cherchera à faire preuve d'empathie envers toutes les personnes de notre équipe. On grandit nous aussi. Il y a beaucoup de commandements. Il y a la liste ici. Si le sujet vous intéresse, je vous renvoie vers la conférence d'Olivier Thelu qui a lieu à MiXit. Et une conférence de Kim Lai Trinh. Il a réussi à faire l'exercice de s'autocritiquer sur ses revues de code parce qu'il s'est rendu compte que même s'il voulait faire mieux, il a parfois manqué d'empathie. Maintenant on essaie de mettre les sentiments de côté et de voir les choses positivement, on va chercher à formater nos commentaires. J'ai demandé à mon réseau s'ils avaient reçu des commentaires qui les avaient un peu vexés. J'en ai reçu beaucoup dont certains qui étaient intentionnellement malintentionnés.
Et j'en ai reçu d'autres dont on n'a pas le contexte mais on peut se poser la question. "Poubelle", c'est mon préféré. "OMG", "Mal écrit". Ces commentaires peuvent être blessants. On peut être tenté de rajouter des émojis pour rendre les choses plus douces et donner l'intention. "Poubelle" avec un smiley, je casse tout si je reçois ça ! C'est pour vous dire que les émojis sont interprétables. On peut faire mieux si je vous propose "Poubelle" avec une suggestion. "OMG avec un éloge". Le préfixe nous ramène vraiment à une pure question de mentorat, d'une volonté de formation. Ça change radicalement la portée du commentaire. Il y a un label obligatoire qui va nous indiquer le contexte du commentaire. On a ensuite des décorations qui sont optionnelles, qui peuvent être bloquantes ou non bloquantes. On a le sujet, qui est le commentaire en lui-même. C'est ce qu'on veut dire à la personne. Et en optionnel, on a la discussion. C'est tout ce qui va ouvrir à l'explication, qui va permettre à la personne d'exploiter les indications que vous lui donnez pour résoudre la situation. Ça peut être un patch, une proposition de code, des liens vers de la doc, une explication plus fouillée, tout ce qui vous semble être intéressant pour aider la personne à avancer dans la résolution du sujet. Des labels, il y en a beaucoup qui sont proposées par le standard. Si vous souhaitez adopter ce standard, vous n'êtes pas obligés de tous les utiliser. On a pris l'éloge, par exemple. On va chercher à souligner quelque chose de positif. On va rester au premier degré. Il y a les suggestions. C'est la majorité des commentaires que l'on peut laisser. On propose des améliorations au sujet actuel. On va chercher à être le plus explicite possible. On va bien expliquer pourquoi il s'agit d'une amélioration. On va proposer des patchs et des décorations bloquantes ou non bloquantes pour que la personne sache si c'est prioritaire ou non. On a les bugs, qu'il faut trouver avant de les mettre en prod. On va mettre en évidence les problèmes que l'on a vus. C'est toujours un couplé avec une suggestion pour amener la résolution du bug. On a aussi les pensées. Ce sont les idées qui nous viennent quand on fait la revue de code. Ce ne sont pas des choses à résoudre dans la feature sur laquelle on est actuellement. Ce n'est pas bloquant. C'est très précieux. Ça peut mener à du mentorat, de l'amélioration globale. Pourquoi je pense que grâce à ce standard, on souffre moins ? On a une meilleure compréhension grâce au label. On a quelque chose de plus lisible. On a un contexte. On va aussi limiter les quiproquos.
On va plus se poser la question du ton qui a été employé. On va moins perdre de temps sur un commentaire qui n'est pas bloquant. Et on va limiter les mauvaises impressions. Notamment, on va réfléchir à l'intention de notre commentaire avant de le publier. On va se demander dans quelle catégorie est-ce qu'il rentre. Est-ce qu'il est vraiment professionnel ? Est-ce qu'il est utile à la personne ? On peut même s'autocensurer. C'est un conseil pour toute la vie en général. Là, on reprend notre poubelle. On a le préfixe nitpick. On indique c'est non bloquant. On a l'explication. On a un patch qui peut être commité directement. Vous allez me dire que c'est trop long, tout préfixer, c'est trop fatigant. Heureusement, Github est là pour vous. Vous pouvez sauvegarder des templates de réponses qui vous permettent d'y accéder rapidement. Vous pouvez utiliser des extensions qui existent. Et vous pouvez vous approprier la méthode. Peut-être que votre équipe n'a pas besoin d'utiliser le standard en entier. Peut-être que votre équipe a besoin de quelques ajustements, de notifier quelle est l'urgence. Je vous envoie un excellent article de Camille Regnault, qui a écrit un article sur la façon dont son équipe utilise ce standard avec des émojis qui traduisent l'intention urgence. Le petit peanuts, si vous avez une review avec 30 commentaires peanuts, vous devez vous dire que l'urgence n'est pas folle. Mais si c'est préfixé par de petites alertes ou par des flammes, vous pouvez penser qu'il faut s'en occuper prioritairement. L'impact sur l'onboarding a été très positif dans mon équipe. J'ai pu me focus sur l'essentiel. J'ai pu savoir tout de suite ce qui était bloquant ou non. J'ai eu des retours utiles et exploitables pour progresser sur la connaissance du fonctionnel et des standards de l'équipe. J'ai trouvé ça absolument positif. Il y a plein d'autres bonnes pratiques d'onboarding. On peut donner une petite première tâche à faire à la personne pour se familiariser avec le workflow, comme rajouter son nom dans une liste de prénoms. On peut aussi alors une personne qui est un buddy. Hier, Amélie nous a parlé des bonnes pratiques dans sa conférence. Et on peut aussi chercher à avoir plus d'interactions humaines. Quand les commentaires commencent à s'empiler, le bon réflexe est d'aller voir les personnes pour en parler. Si vraiment on souffre, les conventional comments ne pourront rien pour vous. Je vous renvoie à la première partie de cette conférence où on parle de posture. Je vous remercie de m'avoir écoutée. Merci aux chats d'avoir participé et merci à mon équipe ! Merci beaucoup à l'équipe des Picsou qui m'ont bien accueillie chez Bedrock. Si vous voulez parler, vous pouvez me retrouver au stand Bedrock. Cherchez-moi ! Merci beaucoup.
Tweets