Code review en JavaScript: qué revisar para que el código no se desmorone

Code review en JavaScript: qué revisar para que el código no se desmorone

¿Alguna vez has abierto un pull request ajeno y has sentido que todo se te encoge por dentro? Como si miraras un enredo de cables donde cada nudo es un error potencial. Code review en JavaScript no es solo una casilla de verificación en el gestor de tareas. Es tu última línea de defensa contra el caos. Especialmente en el dinámico mundo de JS, donde el tipado es una ilusión y el comportamiento «mágico» es la norma.

En este artículo te contaré en qué debes fijarte realmente al revisar código JavaScript. Olvídate de las discusiones sin sentido sobre tabs vs espacios. Hablaremos de cosas que afectan directamente la estabilidad, legibilidad y rendimiento. Esta es la checklist de code review que uso yo mismo.

1. Pureza de las funciones y ausencia de efectos secundarios

El primer punto y el más importante. Una función debe hacer exactamente una cosa y hacerla bien. Si ves una función que simultáneamente valida datos, envía una petición al servidor y actualiza el estado global, eso es una señal de alarma.

Qué revisar:

\n
• Cantidad de argumentos: Idealmente 0, máximo 3. Si hay más, agrúpalos en un objeto de configuración.
\n
• Mutación de datos de entrada: La función no debe modificar el array u objeto que recibe. Es un error grave y difícil de detectar.
\n
• Efectos secundarios: Cualquier cambio en el mundo exterior (console.log, escritura en archivo, modificación del DOM) debe ser explícito y justificado.
\n

Ejemplo malo:

let totalUsers = 0;\n\nfunction processUsers(users) {\n    for (let i = 0; i < users.length; i++) {\n        users[i].active = true; // ¡Mutación de datos de entrada!\n        totalUsers++;           // ¡Efecto secundario!\n        console.log(users[i]);  // Otro efecto secundario\n    }\n    return users;\n}

Ejemplo bueno:

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

Recuerda: las funciones puras son la base de un código predecible. Si en un code review ves una mutación, no dudes en escribir un comentario. Es una de las principales causas de errores difíciles de encontrar en JavaScript.

2. Asincronía: promesas y async/await

JS es el rey de la asincronía, pero también el rey del callback hell. Al revisar, presta atención a cómo se manejan las operaciones asíncronas. La revisión de código JavaScript sin analizar las cadenas de promesas es una farsa.

Señales de alerta:

\n
• Falta de manejo de errores: No hay .catch() ni try/catch. Tarde o temprano, esto hará caer la aplicación.
\n
• Promesas anidadas: Si ves un .then() dentro de otro .then(), es motivo para refactorizar.
\n
• await olvidado: La función está marcada como async, pero las llamadas internas no tienen await. El resultado será undefined en lugar de datos.
\n

Ejemplo malo (falta de manejo de errores):

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

Ejemplo bueno:

async function fetchUserData(userId) {\n    try {\n        const response = await fetch(`/api/users/${userId}`);\n        if (!response.ok) {\n            throw new Error(`¡Error HTTP! estado: ${response.status}`);\n        }\n        return await response.json();\n    } catch (error) {\n        console.error('Error al cargar el usuario:', error);\n        throw error; // Lo relanzamos, pero lo registramos\n    }\n}

Consejo para el revisor: exige siempre una explicación de por qué no hay un bloque try/c