Comment instaurer une culture de revue de code ? Mes observations après dix ans

je suis d'accord avec la règle des petits morceaux mais c'est dur en pratique. parfois le changement est gros par nature.

chez nous la solution a été : avant d'envoyer un gros changement, on écrit l'approche sur une page et on la partage. 5 min de lecture, ça évite une heure de débat en revue.

apprendre qu'on est sur la mauvaise approche après avoir écrit 500 lignes, c'est le pire. à ce stade personne veut revenir en arrière et la mauvaise décision part en prod.

En tant que débutant, je peux dire un truc ?

Pour moi, le plus dur, c'est pas de ne pas prendre les commentaires personnellement. Quand je reçois un commentaire que je ne comprends pas, j'hésite à redemander, j'ai peur de passer pour un idiot. Alors je devine et je corrige mal.

J'sais pas si c'est juste moi mais peut-être que d'autres sont pareils.

C'est pas juste toi, c'est très courant et c'est notre boulot de corriger ça, pas le tien.

Chez nous, deux choses ont marché. D'abord, écrire la justification avec le commentaire. Au lieu de dire "change ça", dire "ça plante dans ce cas, donc c'est mieux comme ça". S'il y a une justification, le besoin de poser des questions diminue.

Ensuite, quand il y a plus de deux tours d'échanges, on passe la conversation en chat. Un appel de 15 min, c'est plus rapide que 15 commentaires et c'est beaucoup moins épuisant.

Et je te dis ça : y'a pas de question bête. Trois autres personnes dans l'équipe se posent la même question que toi mais n'osent pas demander. En demandant, tu rends service aux quatre.

Laisser les débats de style aux outils, c'est déjà le plus gros gain. Ça se met en place en une semaine et ça fait gagner des années de temps.

Un rappel côté gestion de projet : notez le temps de revue dans le planning.

Chez nous, ça s'est passé comme ça : pendant longtemps, on n'a pas considéré la revue comme faisant partie du travail, y'avait que le temps de dev dans le planning. Résultat : chaque revue était vue et présentée comme "ce qui retarde le boulot" et on la faisait pour la forme.

Depuis qu'on l'a mise dans le planning, personne ne sabote plus les revues, parce que c'est plus un truc qui retarde, c'est le planning lui-même.

J'ai vécu la même chose.

C'est exactement ça. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Je le note au cas où.

Je suis entièrement d'accord. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Chez moi, c'est l'inverse qui s'est passé, c'est pourquoi j'écris. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je me permets une petite mise en garde. Avant de décider, regardez quelles données vous avez en main.

Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger. Je suis aussi curieux de savoir si d'autres font autrement.

Je suis intéressé.

Chez nous aussi.

Enregistré.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Commencez par un petit test ne vous engagez pas sur tout d'un coup.

À votre place, j'irais par cette voie.

Désolé, mais ce n'est pas vrai dans tous les cas. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Corrigez-moi si je me trompe.

Il est rare de trouver un texte qui explique les choses aussi clairement. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Si le périmètre s'agrandit, il faut augmenter soit le délai, soit le budget. Il n'y a pas de troisième option. Je suis aussi curieux de savoir si d'autres font autrement.

suejt très actuel.

C'est noté, merci.