Code Review en JavaScript : quoi vérifier et comment donner un retour d'expérience en pratique

Introduction : pourquoi la code review ne consiste pas à "trouver des bugs"

La code review (revue de code) n'est pas une simple formalité ou un moyen de trouver des fautes de frappe. Dans le développement moderne en JavaScript et Node.js, c'est l'outil principal pour maintenir la qualité du code, partager les connaissances au sein de l'équipe et prévenir la dette technique. Cependant, de nombreux développeurs réduisent la revue à une vérification de la syntaxe, négligeant les problèmes architecturaux, les performances et la lisibilité.

Dans cet article, nous allons voir ce qu'il faut exactement vérifier dans le code JavaScript (avec l'exemple de Node.js), et comment donner un retour d'expérience (feedback) sans offenser un collègue, mais en l'aidant à progresser. Des exemples pratiques de code vous aideront à assimiler le contenu.

1. Que vérifier dans le code JavaScript : une checklist pratique

Commençons par des points de vérification concrets. Divisons-les en trois niveaux : syntaxe/style, logique/sécurité et architecture.

1.1. Style de code et formatage

Ici, c'est simple : utilisez un linter (ESLint) et un formateur (Prettier). Il ne devrait pas y avoir de débats sur les espaces lors de la revue. Configurez les fichiers de configuration dans le projet une fois pour toutes. Vérifiez que :

\n
• Le code respecte les règles eslint-config-airbnb ou vos paramètres personnalisés.
\n
• Il n'y a pas de console.log superflus (sauf en mode dev).
\n
• Les noms de variables sont explicites : const userData, et non const x.
\n

1.2. Logique de gestion de l'asynchrone (Promise, async/await)

C'est une zone d'erreurs fréquente dans Node.js. Vérifiez :

\n
• La gestion des erreurs dans les fonctions asynchrones. L'absence de try/catch peut entraîner un crash du processus.
\n
• L'utilisation correcte de await dans les boucles. Si les tâches ne dépendent pas les unes des autres, utilisez Promise.all.
\n

Mauvais :

// Exécution séquentielle alors qu'elle pourrait être parallèle\nconst results = [];\nfor (const id of ids) {\n  const data = await fetchData(id); // On attend chaque requête\n  results.push(data);\n}\n

Bon :

// Exécution parallèle\nconst promises = ids.map(id => fetchData(id));\nconst results = await Promise.all(promises);\n

1.3. Sécurité et fuites de mémoire

Pour Node.js, il est critique :

\n
• Absence d'injections : n'utilisez pas eval ou new Function sans nécessité impérieuse.
\n
• Fermeture des flux (streams), des connexions à la base de données et des descripteurs de fichiers.
\n
• Validation des données d'entrée. Ne faites jamais confiance au corps de la requête (req.body).
\n

2. Comment donner un retour d'expérience : psychologie et tactique

Même une liste de vérifications idéale ne fonctionnera pas si le feedback donne à l'auteur du code l'envie de fermer la PR et de démissionner. Voici quelques règles.

2.1. La règle du "sandwich" (facultative mais efficace)

Commencez par un commentaire positif, puis indiquez le problème, et terminez par un soutien. Par exemple :

\n
• "Excellente solution avec l'utilisation de Map pour la mise en cache !"
\n
• "Cependant, il y a ici un problème potentiel de mutation du tableau d'origine. Utilisons .map() au lieu de .forEach() avec push."
\n
• "Pour le reste, le code est propre, merci pour le correctif rapide !"
\n

2.2. Commentez le code, pas la personne

Au lieu de "Tu as écrit une boucle horrible", dites "Cette boucle peut être remplacée par Array.reduce pour améliorer la lisibilité". Évitez le pronom "tu" dans un contexte négatif.

2.3. Donnez du contexte et des alternatives

Écrire simplement "C'est faux" est mauvais. Expliquez pourquoi et proposez une alternative. Exemple de mauvais commentaire :

"N'utilise pas var."

Bon commentaire :

"Ici, var crée une variable dans la portée globale, ce qui peut entraîner des bugs. Remplaçons-la par const, car la valeur n'est pas réaffectée."