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

Code review en TypeScript: qué revisar y cómo dar retroalimentación en la práctica

El code review no es solo una formalidad, sino una herramienta poderosa para mejorar la calidad del código. En TypeScript, con su rico sistema de tipos, la revisión puede ser especialmente efectiva. En este artículo, analizaremos en qué fijarse al revisar código TypeScript y cómo dar retroalimentación para que sea útil, no ofensiva. Todos los ejemplos son con código real.

1. Tipos y anotaciones: evita `any` y usa el rigor

Lo primero que salta a la vista en una revisión de código TypeScript son los tipos. TypeScript está diseñado para detectar errores en tiempo de compilación, por lo que any es una bandera roja.

Qué revisar:

\n
• Presencia de any. Cada any debe estar justificado. Si es una migración desde JS, está bien, pero en código nuevo, no.
\n
• Corrección de los tipos. No uses string donde se necesita un enum o un union type.
\n
• Tipado excesivo. TypeScript puede inferir tipos. No escribas const x: number = 5 — escribe const x = 5.
\n
• Configuraciones estrictas. Verifica que en tsconfig.json estén habilitados strict: true, noImplicitAny, strictNullChecks.
\n

Ejemplo de código malo:

function processData(data: any) {\n  return data.name.toLowerCase();\n}

Cómo corregirlo:

interface User {\n  name: string;\n}\n\nfunction processData(data: User): string {\n  return data.name.toLowerCase();\n}

Cómo dar retroalimentación:

En lugar de «Estás usando any, eso es malo», di: «Aquí any desactiva la verificación de tipos. Describamos la interfaz User — esto mejorará la seguridad y legibilidad del código».

2. Trabajo con null y undefined: strictNullChecks salva vidas

Los errores Cannot read property of undefined son clásicos. TypeScript con strictNullChecks ayuda a evitarlos, pero solo si el desarrollador maneja correctamente los valores nullable.

Qué revisar:

\n
• Verificación de null/undefined antes de acceder a propiedades.
\n
• Uso de optional chaining (?.) — es moderno y seguro.
\n
• Operador ! (non-null assertion) — úsalo solo si estás 100% seguro de que el valor no es null. Es mejor reemplazarlo con una verificación explícita.
\n
• Uso correcto de ?? (nullish coalescing) en lugar de || para valores por defecto.
\n

Ejemplo de código malo:

function getCity(user: User | null): string {\n  return user!.address!.city; // ¡Peligroso!\n}

Cómo corregirlo:

function getCity(user: User | null): string {\n  return user?.address?.city ?? 'Unknown';\n}

Cómo dar retroalimentación:

«El uso de ! aquí es riesgoso — si user resulta ser null, se producirá un error. Reemplacémoslo con ?. y ?? — es seguro y legible».

3. Genéricos y tipos utilitarios: no compliques sin necesidad

Los genéricos son una característica poderosa, pero es fácil complicarlos demasiado. El revisor debe buscar un equilibrio entre flexibilidad y legibilidad.

Qué revisar:

\n
• Complejidad excesiva. Si un genérico se usa solo una vez, quizás no sea necesario.
\n
• Uso correcto de extends — restringe los genéricos para que no acepten cualquier cosa.
\n
• Tipos utilitarios (Partial, Pick, Omit, Record) — su uso simplifica el código.
\n
• Tipos de valores de retorno — una función con genéric