- Tu es en mode "reviewer". Tu ouvres une PR. Avant de cliquer “Comment”, prends une seconde.
Respire. Mets-toi à la place de celui qui a écrit ce code.
1.1. Commence par comprendre le “pourquoi”
“Je ne comprends pas ce qu’il a voulu faire…”
→ C’est peut-être toi qui n’as pas assez lu.
- Avant de lire une ligne de code, lis la description de la PR.
Quel est l’objectif ?
Quel ticket est associé ?
Quels tests ont été faits ?
- Sois le facilitateur :
“Salut ! Pourrais-tu ajouter un petit paragraphe sur l’objectif de ce changement ? Ça m’aiderait à mieux comprendre le contexte. Merci !”
- Un modèle de PR standardisé (sur GitHub ou GitLab) peut tout changer. Exemple de sections utiles :
- 🎯 Objectif
- 🔧 Changements clés
- ✅ Tests effectués
- ⚠️ Points d’attention
Moins d’allers-retours, plus de clarté.
1.2. Lis le code… comme si tu devais le maintenir demain
Imagine que tu dois reprendre ce code dans 6 mois, sans personne pour t’expliquer.
Pose-toi ces questions simples :
Est-ce lisible ?
Est-ce que ça respecte les conventions de l’équipe ?
Y a-t-il des bugs cachés ou des problèmes de performance ?
Est-ce vraiment nécessaire ? Est-ce testé ?
Exemple concret :
Tu vois une boucle for imbriquée sur une liste de 10 000 éléments.
→ Complexité : O(n²).
→ En production, ça pourrait planter.
Au lieu de dire : “C’est lent”,
Propose :
“On pourrait utiliser un Set ici ? Ça réduirait la complexité à O(n), et ça éviterait un ralentissement en production.”
→ Tu aides, tu n’humilies pas.
1.3. Donne un feedback qui construit, pas qui casse
Le ton, c’est tout.
Compare ces deux messages :
“C’est mal nommé. À refaire.”
✅ “La variable tmp est un peu vague. Et si on l’appelait userSessionId ? Comme ça, tout le monde saura ce qu’elle contient.”
La différence ? → La bienveillance.
- Voici trois formules magiques :
- La suggestion douce : “On pourrait extraire cette logique dans une fonction ? Comme ça, on pourrait la réutiliser ailleurs.”
- La question ouverte : “Pourquoi avoir choisi cette approche ? Y avait-il une contrainte spécifique ?”
- La distinction claire :“Ce point est bloquant (sécurité), mais le nom de la variable, c’est juste une suggestion.”
- Utilise des labels :
- 🔴 Blocking : sécurité, bug critique
- 💡 Suggestion : amélioration possible
- ✨ Nitpick : détail de style (indentation, nommage)
Et quand tu cites un standard (ex. : Clean Code), ajoute un lien.
→ C’est un geste pédagogique.
1.4. Transforme la review en dialogue, pas en monologue
La code review, c’est une discussion, pas un verdict.
Si un changement est complexe, propose une session en pair-programming.
Ou un appel rapide sur Slack/Teams.
“Je ne suis pas 100 % sûr de comprendre ton approche. On fait un petit call de 10 min ?”
→ Tu montres que tu veux comprendre, pas imposer.
Et parfois… c’est toi qui apprends.
Ahmed Oumezzine
