Code review en JavaScript : que vérifier pour que le code ne s'effondre pas

Code review en JavaScript : que vérifier pour que le code ne s'effondre pas

Avez-vous déjà ouvert une pull request d'un autre développeur et ressenti comme un serrement à l'intérieur ? Comme si vous regardiez un enchevêtrement de câbles où chaque nœud est un bug potentiel. Le code review en JavaScript n'est pas simplement une case à cocher dans le gestionnaire de tâches. C'est votre dernier rempart contre le chaos. Surtout dans le monde dynamique de JS, où le typage est une illusion et où le comportement « magique » est la norme.

Dans cet article, je vais vous expliquer sur quoi il faut vraiment se concentrer lors de la revue de code JavaScript. Oubliez les débats sans fin sur les tabulations vs les espaces. Nous allons parler des éléments qui impactent directement la stabilité, la lisibilité et les performances. C'est la checklist de code review que j'utilise moi-même.

1. Pureté des fonctions et absence d'effets de bord

Le premier et le plus important point. Une fonction doit faire exactement une chose et la faire bien. Si vous voyez une fonction qui valide des données, envoie une requête au serveur et met à jour l'état global en même temps, c'est un signal d'alarme.

Que vérifier :

\n
• Nombre d'arguments : Idéalement 0, maximum 3. Si c'est plus, regroupez-les dans un objet de configuration.
\n
• Mutation des données d'entrée : La fonction ne doit pas modifier le tableau ou l'objet passé. C'est un bug difficile à détecter.
\n
• Effets de bord : Toute modification du monde extérieur (console.log, écriture dans un fichier, modification du DOM) doit être explicite et justifiée.
\n

Mauvais exemple :

let totalUsers = 0;\n\nfunction processUsers(users) {\n    for (let i = 0; i < users.length; i++) {\n        users[i].active = true; // Mutation des données d'entrée !\n        totalUsers++;           // Effet de bord !\n        console.log(users[i]);  // Encore un effet de bord\n    }\n    return users;\n}

Bon exemple :

function activateUsers(users) {\n    return users.map(user => ({ ...user, active: true }));\n}\n\n// Utilisation :\nconst activeUsers = activateUsers(users);\nconsole.log(`Activé : ${activeUsers.length}`);

Souvenez-vous : les fonctions pures sont la base d'un code prévisible. Si lors d'un code review vous voyez une mutation, n'hésitez pas à écrire un commentaire. C'est l'une des principales causes de bugs difficiles à trouver en JavaScript.

2. Asynchronisme : promesses et async/await

JS est le roi de l'asynchronisme, mais aussi le roi de l'enfer des callbacks. Lors de la revue, faites attention à la façon dont les opérations asynchrones sont gérées. La vérification de code JavaScript sans analyse des chaînes de promesses est une perte de temps.

Drapeaux rouges :

\n
• Absence de gestion des erreurs : Pas de .catch() ni de try/catch. Tôt ou tard, cela fera planter l'application.
\n
• Promesses imbriquées : Si vous voyez un .then() à l'intérieur d'un autre .then(), c'est une raison de refactoriser.
\n
• await oublié : La fonction est marquée comme async, mais les appels à l'intérieur sont sans await. Résultat : undefined au lieu des données.
\n

Mauvais exemple (absence de gestion des erreurs) :

async function fetchUserData(userId) {\n    const response = await fetch(`/api/users/${userId}`);\n    const data = await response.json();\n    return data;\n}

Bon exemple :

async function fetchUserData(userId) {\n    try {\n        const response = await fetch(`/api/users/${userId}`);\n        if (!response.ok) {\n            throw new Error(`Erreur HTTP ! statut : ${response.status}`);\n        }\n        return await response.json();\n    } catch (error) {\n        console.error('Erreur de chargement de l\'utilisateur :', error);\n        throw error; // On propage, mais on logge\n    }\n}

Conseil pour le relecteur : exigez toujours une explication sur pourquoi le try/c