Tu fais encore des codes reviews ? So 2024 🤯
Dans ma dernière vidéo Youtube, j’ai une phrase sur les codes reviews et elle a déclenché la moitié des commentaires.
Si je dois précis, mon propos, c'est plus de dire que la preuve que l’IA change notre métier, c’est que les équipes qui l’adoptent changent leur process et en particulier la code Review.
Alors laisse-moi te donner 5 raisons de ne plus faire de Code Review
1 - Faire relire ton code à un humain lorsque tu l’as généré avec une IA et pas relu toi-même c’est aberrant 😵
2- Les conversations sur l’archi de la fonctionnalité devraient avoir lieu avant, pas après. C’est relou de devoir tout refaire alors que c’était fini. Faites-le en début de sprint. Faites un sprint reniement si vous aimez le SCRUM
3- Tu as peur de péter la prod si un humain ne relit pas ton code ? Le problème, c'est la QA. C’est plus une revue de code, c'est une double recette. Si tu as peur de pusher sur master, la qualité du logiciel et de la CI est un problème et la revue de code n’est pas la solution 🚒
4 - La personne qui relit ton code n’a probablement aucune idée du contexte. Elle va juste fignoler deux trois noms de variables sans pouvoir critiquer plus que ça 🔍
5 - La code review ça permet de s’approprier le code des autres. Cool mais on a besoin de bloquer la MEP pour ça ? Envoie le code en prod et on le regarde ensemble après. ☄️
Alors je ne dis pas que la Code Review n’est plus une best practice.
Par contre, la rendre obligatoire ou indispensable, c’est inutile.
Déjà ça fait perdre du temps aux leads qui peuvent parfois passer 2
jours par semaine à relire le code des autres alors qu’il devrait déjà être en prod.
C’est principalement du flicage des devs. Franchement on est pas sur une plateforme offshore avec 150 pisseurs de code. C’est des équipes avec des ingénieurs compétents, on peut leur faire confiance.
Quand utiliser la Code Review ?
🏟️ Faites du Mob. Si le but est de partager la connaissance du code, autant le faire en One-to-many, le one-to-one c’est pas assez efficace
👀 Faire une PR et demander son avis de manière asynchrone à un collègue
😺 N’hésitez pas à sauter en Visio et regarder le code ensemble
Et croyez-moi, c’est un principe Craft que je prône ici. Les interactions entre les humains sont bien plus importantes que les processus. Alors jetez les PR barbantes et parlez-vous le plus tôt possible.
Je plussoie !
D’autres gardes fous sont généralement plus efficaces dans la durée.. Prendre du temps sur une CI/CD est un bon investissement (lint, sonar,..)
Une staging avec du testing ! (sélénium, sentry, sont des amis) permet de mettre en place les bons fusibles.⚖️
L’inconvénient des CR, est qu’elles (oui au feminin ´review’ Vianney Lecroart ;-) peuvent déresponsabiliser les dev dans la relecture et refacto de leur code.
Oui, oui, c’est pas parce que ca tombe en marche que l’on met en prod 🤓 et surtout pas le vendredi 🍻
CTO @Pharaday ☀️ | Former Head Of Engineering @Gojob | Tech leader, entrepreneur and maker
7 months ago
Perso les reviews me servent plus a faire monter en competences des dev plus juniors ou moins familiers avec notre stack.
Car on le sais tous, la docs, les ressources sur l’archi du projet, les bonne pratique bien décrites, etc.. ca reste souvent le faible des stacks techniques dans les boites.
Et pour le coup je sais pas si une ia pourrait chopper ce contexte local, si tant est qu’il existe ailleurs que dans la tete des leads tech 🤣