Día típico de un desarrollador TypeScript: código, errores y revisiones

Buenos días, TypeScript: cómo comienza el día de un desarrollador

Imagínese: 9:00 a.m. Abre su portátil, prepara café y ve en Telegram un mensaje de un colega: «Oye, ayer escribí una función, pero TypeScript se queja del tipo unknown. ¡Ayuda!». ¿Le suena familiar? Bienvenido al día laboral típico de un desarrollador TypeScript. No se trata solo de escribir código, es el arte de equilibrar entre el tipado estricto, los plazos y las interminables refactorizaciones.

En este artículo, le mostraré un día real en la vida de un desarrollador de TypeScript: desde la reunión matutina hasta el commit vespertino. Verá ejemplos vivos de código, problemas típicos y formas de resolverlos. ¡Allá vamos!

Mañana: reunión diaria y revisión de código

9:30 — Daily standup

Una breve reunión con el equipo. Usted dice: «Ayer terminé el módulo de autorización, hoy planeo trabajar en el tipado de las respuestas de la API». Y al instante escucha: «¿Y no quieres mover las interfaces a un archivo separado? Tenemos un code style». Un desarrollador TypeScript siempre piensa un paso adelante: interfaces, genéricos, utility types.

Ejemplo: discuten el tipado de la respuesta del servidor. En lugar de escribir any, usted propone:

interface ApiResponse<T> {\n  data: T;\n  error: string | null;\n  status: number;\n}\n\ntype User = {\n  id: string;\n  name: string;\n  email: string;\n};\n\n// Uso\nconst response: ApiResponse<User[]> = await fetchUsers();\n

Los colegas asienten: es el enfoque correcto. Un desarrollador TypeScript sabe: un buen tipado es la mitad del éxito.

10:00 — Revisión de código: encontramos errores antes de que ellos nos encuentren

Después de la reunión, abre un Pull Request de un junior. Escribió una función para validar email. El código funciona, pero TypeScript sugiere: Type 'string | undefined' is not assignable to type 'string'. Usted deja un comentario:

// ❌ Problema: no se manejan null/undefined\nfunction validateEmail(input: string | null | undefined): boolean {\n  if (!input) return false;\n  const emailRegex = /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/;\n  return emailRegex.test(input);\n}\n\n// ✅ Solución: usamos guards y optional chaining\nfunction validateEmail(input: unknown): input is string {\n  return typeof input === 'string' && \n         input.length > 0 && \n         /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(input);\n}\n

Usted explica: Un desarrollador TypeScript siempre piensa en los casos límite. El tipado no se trata de limitaciones, sino de seguridad.

Mediodía: escritura de código y trabajo con genéricos

11:30 — Tarea principal del día: refactorización de código heredado

Se enfrenta a un módulo antiguo de JavaScript que debe reescribir en TypeScript. Hay una función que acepta «cualquier cosa» y devuelve «cualquier cosa». Un clásico:

// 🚫 Código JS antiguo\nfunction processData(data) {\n  if (data.type === 'user') {\n    return { id: data.id, name: data.name };\n  }\n  if (data.type === 'order') {\n    return { orderId: data.id, total: data.total };\n  }\n  return null;\n}\n

Lo convierte en código fuertemente tipado usando uniones discriminadas:

// ✅ Versión TypeScript\ntype UserData = { type: 'user'; id: string; name: string };\ntype OrderData = { type: 'order'; id: string; total: number };\ntype InputData = UserData | OrderData;\n\ntype ProcessedResult<T> = T extends UserData \n  ? { id: string; name: string }\n  : T extends OrderData \n  ? { orderId: string; total: number }\n  : never;\n\nfunction processData<T extends InputData>(data: T): ProcessedResult<T> {\n  if (data.type === 'user') {\n    return { id: data.id, name: data.name } as ProcessedResult<T>;\n  }\n  return { orderId: data.id, total: data.total } as ProcessedResult<T>;\n}\n

Ahora TypeScript deduce automáticamente el tipo correcto del resultado según los datos de entrada. Colegas