Code review en JavaScript: qué revisar y cómo dar retroalimentación

Code review en JavaScript: qué revisar y cómo dar retroalimentación para principiantes

El code review (o revisión de código) es el proceso de verificar el código de software por parte de uno o varios desarrolladores antes de que llegue a la rama principal del proyecto. Para los principiantes, este procedimiento a menudo parece intimidante: "¿Y si paso por alto un error?", "¿Cómo le digo a un colega que su código es malo sin arruinar la relación?".

En este artículo, analizaremos en qué fijarse al hacer code review en JavaScript (incluyendo Node.js) y cómo dar retroalimentación para que sea útil, no ofensiva. El material está dirigido a desarrolladores principiantes que recién comienzan a participar en revisiones.

Qué revisar en el código JavaScript: lista de verificación para principiantes

Para que la revisión sea estructurada, dividamos la verificación en varios bloques clave. No intentes abarcarlo todo de una vez: comienza con los puntos más críticos.

1. Funcionalidad y lógica

Ante todo, asegúrate de que el código resuelve la tarea planteada. Ejecútalo localmente (si es posible) o recorre mentalmente todas las ramas de ejecución. Estas son las preguntas típicas:

\n
• ¿Se manejan correctamente los casos límite (array vacío, null, undefined)?
\n
• ¿Hay "números mágicos" (números sin explicación, por ejemplo if (x > 86400) en lugar de const ONE_DAY_IN_SECONDS = 86400)?
\n
• ¿Funciona correctamente el código asíncrono (Promise, async/await)?
\n

// Mal: número mágico\nif (user.lastLogin < Date.now() - 86400000) { ... }\n\n// Bien: constante con nombre\nconst ONE_DAY_MS = 24 * 60 * 60 * 1000;\nif (user.lastLogin < Date.now() - ONE_DAY_MS) { ... }

2. Estilo de código y formato

Aunque muchos proyectos usan Prettier y ESLint, vale la pena verificar manualmente:

\n
• Cumplimiento de un estilo uniforme (sangrías, comillas, punto y coma).
\n
• Nombres correctos de variables, funciones y clases (camelCase para variables, PascalCase para clases).
\n
• Ausencia de código comentado: solo ensucia el archivo.
\n

// Mal: nombre poco informativo\nconst d = new Date();\nconst arr = getData(d);\n\n// Bien: el nombre describe la esencia\nconst currentDate = new Date();\nconst usersData = fetchUsersData(currentDate);

3. Rendimiento y seguridad

Para Node.js son especialmente importantes:

\n
• Evitar operaciones bloqueantes en el hilo principal (lectura síncrona de archivos, bucles pesados).
\n
• Verificar fugas de memoria (por ejemplo, temporizadores o listeners de eventos olvidados).
\n
• Validación de la entrada del usuario (protección contra inyecciones SQL, XSS).
\n

// Mal: la lectura síncrona bloquea el Event Loop\nconst data = fs.readFileSync('bigfile.json', 'utf8');\n\n// Bien: lectura asíncrona\nconst data = await fs.promises.readFile('bigfile.json', 'utf8');

Cómo dar retroalimentación: principios de una revisión constructiva

Ahora que sabes qué revisar, analicemos la habilidad principal del code review: saber comunicar las observaciones. Tu objetivo es mejorar el código, no reafirmarte a costa del autor.

1. Sé específico y fundamentado

En lugar de "Este código es malo", escribe: "Aquí hay un posible problema de rendimiento: la llamada a Array.find() dentro de un bucle da una complejidad de O(n²). Reemplacémoslo con un Map". El autor entenderá exactamente qué está mal y cómo corregirlo.

2. Usa mensajes en primera persona y haz preguntas

Frases como "No estoy seguro de que este código maneje el caso de un array vacío. ¿Podemos agregar una verificación?" suenan más suaves que "Olvidaste manejar el array vacío". Esto reduce la reacción defensiva y estimula el diálogo.

3. Elogia las buenas soluciones

El code review no es solo crítica. Si ves una solución elegante o una excelente arquitectura, asegúrate de señalarlo. Por ejemplo: "Excelente idea la de extraer