JavaScript : ce que les seniors recherchent dans le code et ce qui leur fait mettre un moins

Revue de code JavaScript : ce qui agace vraiment les seniors

Chaque développeur a déjà reçu une pull request avec un commentaire du genre « il vaut mieux réécrire ça » ou « c'est un antipattern ». Si vous êtes Junior ou Middle, ces remarques semblent souvent être des chicaneries. Mais derrière chaque mot d'un senior se cache une expérience réelle : un incident en production, un bug à trois heures du matin ou une baisse de performance.

Nous avons rassemblé les remarques les plus fréquentes que les seniors laissent lors des revues de code JavaScript. Ce n'est pas juste une liste « c'est mauvais, c'est bien ». C'est une analyse pourquoi une approche particulière est considérée comme mauvaise et par quoi on peut la remplacer.

Cet article sera utile à tous ceux qui écrivent en JS : des débutants aux développeurs expérimentés qui souhaitent améliorer la qualité de leur code.

1. Mutation des données d'entrée : le péché capital

Une des erreurs les plus fréquentes en revue — modifier les objets ou tableaux passés à une fonction. Les seniors détestent cela car la mutation brise l'immutabilité et entraîne des bugs difficiles à tracer.

Mauvais exemple

function addUser(users, newUser) {\n  users.push(newUser); // mutation du tableau d'origine !\n  return users;\n}\n\nconst allUsers = [{ id: 1 }, { id: 2 }];\nconst updated = addUser(allUsers, { id: 3 });\nconsole.log(allUsers.length); // 3 — le tableau d'origine est modifié !

Comment faire

function addUser(users, newUser) {\n  return [...users, newUser]; // on retourne un nouveau tableau\n}\n\nconst allUsers = [{ id: 1 }, { id: 2 }];\nconst updated = addUser(allUsers, { id: 3 });\nconsole.log(allUsers.length); // 2 — l'original n'est pas touché

Pourquoi c'est important : lorsque vous mute les données d'entrée, tout autre code qui référence le même objet reçoit des modifications inattendues. C'est un chemin direct vers des bugs dans les opérations asynchrones, les stores Redux et les états React.

2. Nombres et chaînes magiques : tueurs de lisibilité

Les seniors écrivent souvent dans les commentaires : « C'est quoi ce nombre 86400 ? » ou « D'où vient cette chaîne ? ». Les valeurs magiques rendent le code incompréhensible et compliquent sa maintenance.

Mauvais exemple

function calculateDiscount(price) {\n  if (price > 1000) {\n    return price * 0.9;\n  }\n  return price * 0.95;\n}

Comment faire

const DISCOUNT_THRESHOLD = 1000;\nconst HIGH_DISCOUNT_RATE = 0.9;\nconst STANDARD_DISCOUNT_RATE = 0.95;\n\nfunction calculateDiscount(price) {\n  if (price > DISCOUNT_THRESHOLD) {\n    return price * HIGH_DISCOUNT_RATE;\n  }\n  return price * STANDARD_DISCOUNT_RATE;\n}

Conseil : extrayez toutes les constantes dans des variables nommées ou un fichier de configuration séparé. Cela simplifie la revue de code JavaScript et le rend auto-documenté.

3. Erreurs avec async/await et les promesses

Le code asynchrone est une zone où même les middles trébuchent. Les seniors en revue prêtent attention à deux points principaux : la mauvaise gestion des erreurs et le mélange des syntaxes.

Mauvais exemple (promesse sans catch)

async function loadData() {\n  const response = await fetch('/api/data');\n  const data = await response.json();\n  return data;\n}

Comment faire

async function loadData() {\n  try {\n    const response = await fetch('/api/data');\n    if (!response.ok) {\n      throw new Error(`HTTP error! status: ${response.status}`);\n    }\n    const data = await response.json();\n    return data;\n  } catch (error) {\n    console.error('Erreur de chargement des données :', error);\n    throw error; // on propage si nécessaire\n  }\n}

Important : n'ignorez jamais les erreurs. Un catch vide est un mal. Si une erreur se produit, vous devez au moins la journaliser, et mieux encore, la gérer correctement.

Une autre erreur fréquente — await oublié

function processUsers(users) {\n  users.forEach(async (user) => {\n    await updateUser(user);