Revisión de código en TypeScript: 10 errores que enfurecen a los seniors

Introducción: ¿Por qué su revisión de código en TypeScript parece una luz roja en el panel de control?

¿Alguna vez ha enviado un pull request y una hora después recibió 20 comentarios de un desarrollador senior, la mitad de los cuales comenzaban con las palabras «esto se puede hacer mejor»? ¿Le suena familiar? Si escribe en TypeScript, pero su código aún hace que sus colegas quieran reescribirlo desde cero, este artículo es para usted.

En PythonLib a menudo nos encontramos con situaciones en las que los desarrolladores, incluso conociendo la sintaxis de TypeScript, cometen los mismos errores. Estos errores no rompen el código, pero lo hacen ilegible, inseguro y difícil de mantener. Hoy les mostraré 10 comentarios típicos que los seniors escriben en un code review TypeScript y cómo evitarlos. ¡Prepárense para la refactorización!

1. «Any» es tu enemigo, no tu amigo

La queja más común en cualquier revisión de código en TypeScript es el uso de any. Parece que es más fácil escribir const data: any = await fetch(...) que lidiar con los tipos. Pero los seniors lo ven como un trapo rojo.

Mal:

function processUser(user: any) {  console.log(user.name.toUpperCase());}

Bien:

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

¿Por qué es importante? TypeScript pierde todo su sentido si usas any. Literalmente estás desactivando el sistema de tipos. Si los datos vienen de una API, crea una interfaz. Si el tipo es complejo, usa unknown con comprobaciones. Esta es una de las principales reglas de TypeScript best practices.

2. Ignorar el strict mode

Muchos proyectos desactivan el modo estricto en tsconfig.json porque «es más rápido» o «los tipos molestan». Un desarrollador senior de TypeScript notará de inmediato que tu código no verifica null y undefined.

Mal (strict: false):

function getLength(str: string) {  return str.length; // str puede ser null y esto fallará}

Bien (strict: true):

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

Consejo: Activa strict: true en tsconfig.json. Esto te obligará a escribir código más seguro. En una revisión de código TypeScript será un punto a favor, no en contra.

3. Magia con tipos: complejidad excesiva

A veces los desarrolladores intentan demostrar lo buenos que son y escriben tipos que incluso los seniors se rascan la cabeza. Por ejemplo, tipos condicionales con genéricos anidados donde se podría usar una interfaz simple.

Mal (over-engineering):

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

Bien (simplicidad):

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

Los seniors valoran la legibilidad del código. Si tu tipo se puede reemplazar por una interfaz con tres campos, hazlo. No compliques sin necesidad.

4. Manejo incorrecto de errores

Un error típico en un code review TypeScript es un try-catch con any o un bloque catch vacío. Los seniors lo señalarán de inmediato.

Mal:

try {  const data = await fetchData();} catch (e) {  console.log('Error');}

Bien:

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('Error desconocido', error);  }}

Usa unknown para los errores. Esto es