Donner une revue en tant que personne qualité
Un jour un développeur vous ajoute comme relecteur sur sa PR. Ce pour quoi vous êtes là n'est pas ce pour quoi les autres relecteurs sont là.
Votre prisme : risque et testabilité
- Qu'est-ce qui casse si ça sort mal — et ce chemin est-il testé ?
- Le changement bouge-t-il quelque chose dont les tests dépendent — sélecteurs, timing, formes de données ?
- De nouveaux états visibles par l'utilisateur sans couverture ?
- Le chemin d'erreur — que voit l'utilisateur quand ça échoue ?
Pas votre affaire
Le style que le linter devrait attraper. L'architecture que l'équipe a déjà choisie. Réécrire leur approche en celle que vous auriez utilisée. Une revue qui rejuge des décisions réglées vous fait retirer de la liste des relecteurs — poliment, et définitivement.
Une formulation qui marche
Les questions battent les verdicts. « Que se passe-t-il si l'API expire ici ? » ouvre une conversation ; « c'est faux » ouvre une bagarre. Vous pouvez soulever chaque risque que vous voyez sans une seule phrase déclarative.
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