JavaScript: qué buscan los seniors en el código y por qué ponen un menos

Revisión de código en JavaScript: lo que realmente enfurece a los seniors

Cada desarrollador ha recibido al menos una vez un pull-request con un comentario como «mejor reescribe esto» o «esto es un antipatrón». Si eres Junior o Middle, estas observaciones a menudo parecen quejas. Pero detrás de cada palabra de un senior hay experiencia real: una falla en producción, un error a las tres de la madrugada o una caída de rendimiento.

Hemos recopilado las observaciones más frecuentes que los seniors dejan en las revisiones de código en JavaScript. No es solo una lista de «esto está mal, esto está bien». Es un análisis de por qué un enfoque específico se considera malo y con qué se puede reemplazar.

El artículo será útil para todos los que escriben en JS: desde principiantes hasta desarrolladores experimentados que quieren mejorar la calidad del código.

1. Mutación de datos de entrada: el pecado capital

Uno de los errores más comunes en las revisiones es modificar objetos o arrays pasados a una función. Los seniors odian esto porque la mutación rompe la inmutabilidad y provoca errores difíciles de rastrear.

Ejemplo incorrecto

function addUser(users, newUser) {\n  users.push(newUser); // ¡mutación del array original!\n  return users;\n}\n\nconst allUsers = [{ id: 1 }, { id: 2 }];\nconst updated = addUser(allUsers, { id: 3 });\nconsole.log(allUsers.length); // 3 — ¡el array original fue modificado!

Cómo debería ser

function addUser(users, newUser) {\n  return [...users, newUser]; // devolvemos un nuevo array\n}\n\nconst allUsers = [{ id: 1 }, { id: 2 }];\nconst updated = addUser(allUsers, { id: 3 });\nconsole.log(allUsers.length); // 2 — el original no se toca

Por qué es importante: cuando mutas los datos de entrada, cualquier otro código que haga referencia al mismo objeto recibe cambios inesperados. Esto es un camino directo a errores en operaciones asíncronas, stores de Redux y estados de React.

2. Números y cadenas mágicas: asesinos de la legibilidad

Los seniors suelen escribir en los comentarios: «¿Qué número es 86400?» o «¿De dónde salió esta cadena?». Los valores mágicos hacen que el código sea incomprensible y dificultan su mantenimiento.

Ejemplo incorrecto

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

Cómo debería ser

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}

Consejo: extrae todas las constantes en variables con nombre o en un archivo de configuración separado. Esto simplifica la revisión de código en JavaScript y lo hace autodocumentado.

3. Errores con async/await y promesas

El código asíncrono es un área donde incluso los mid-level tropiezan. Los seniors en las revisiones se centran en dos puntos principales: manejo incorrecto de errores y mezcla de sintaxis.

Ejemplo incorrecto (promesa sin catch)

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

Cómo debería ser

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('Error al cargar datos:', error);\n    throw error; // lo propagamos si es necesario\n  }\n}

Importante: nunca ignores los errores. Un catch vacío es malo. Si ocurre un error, al menos debes registrarlo, y mejor aún, manejarlo correctamente.

Otro error frecuente: olvidar el await

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