Recevoir une revue sans le prendre personnellement
Onze commentaires sur votre première PR ressemblent à une attaque. C'est le contraire — le silence est la façon dont les équipes traitent le code qu'elles ont abandonné.
Le vocabulaire
- nit: — mineur, à prendre ou à laisser. Pas une exigence.
- Bloquant / changements demandés — un statut, pas une humeur. Corrigez, répondez, re-demandez.
- « Pourquoi pas X ? » — généralement une vraie question, pas rhétorique. Répondez-y comme telle.
Quoi faire de chaque commentaire
D'accord → corrigez et répondez « fait ». Pas d'accord → dites pourquoi une fois, avec une raison sur le code : « gardé l'attente conditionnelle car la modale se rend en async sur les builds lents ». Pas clair → demandez. Le seul mauvais geste est le silence.
Quand repousser est juste
Quand vous savez quelque chose que le relecteur ignore — vous avez testé l'alternative, il y a une contrainte qu'il ne voit pas. Repoussez au nom du code, jamais du vôtre. « J'ai essayé getByRole ici ; c'est ambigu parce qu'il y a deux boutons » termine le fil en un message.
Basé sur la façon dont la revue de code se déroule dans les vraies équipes
Toutes les leçons de Travailler comme un ingénieur : Git, PRs & revue de code
- La boucle : branche, commit, PR, merge
- Votre premier conflit de merge
- Lire du code que vous n'avez pas écrit
- Recevoir une revue sans le prendre personnellement
- Donner une revue en tant que personne qualité
- Des commits et PRs qu'un examinateur lira