Escribe funciones mantenibles con firmas robustas, callbacks tipados y errores más predecibles.
En TypeScript, una función bien tipada es un contrato verificable, no solo una implementación que "parece" correcta.
Definir parámetros y retornos con precisión evita cascadas de checks defensivos en capas superiores.
Una firma clara también documenta intención de negocio: qué casos soporta, qué errores modela y qué invariantes mantiene.
Esta lección se centra en escribir funciones que sobreviven cambios de requisitos sin degradar legibilidad.
Una firma útil habla del problema de negocio, no del detalle accidental de implementación.
Agrupa parámetros que viajan juntos en objetos tipados para evitar funciones con listas largas y frágiles.
Nombra tipos con vocabulario del producto (OrderDraft, UserRole) y no con etiquetas genéricas (Data, Payload).
Cuando un parámetro es opcional, define claramente su semántica y evita que signifique varias cosas a la vez.
Si una función puede fallar, su tipo de retorno debe hacerlo visible.
Devolver null sin contexto desplaza el problema al consumidor. Es preferible usar un resultado discriminado de éxito/error.
Este patrón mejora testabilidad porque cada rama tiene contrato explícito y assertions concretas.
También reduce excepciones ocultas: el flujo de error queda en la firma y no enterrado en logs o catch genéricos.
Al pasar funciones como argumento, tipar bien la interfaz evita bugs de acoplamiento.
Define tipos de callback reutilizables cuando varios módulos comparten la misma forma de interacción.
Evita any en callbacks: suele ocultar discrepancias entre productor y consumidor de eventos.
Si una función compone otras, declara su retorno explícito para que el pipeline completo sea predecible.
Escribe funciones mantenibles con firmas robustas, callbacks tipados y errores más predecibles.
Código del tema: funciones robustas
Una firma útil habla del problema de negocio, no del detalle accidental de implementación.
Agrupa parámetros que viajan juntos en objetos tipados para evitar funciones con listas largas y frágiles.
Nombra tipos con vocabulario del producto (OrderDraft, UserRole) y no con etiquetas genéricas (Data, Payload).
Cuando un parámetro es opcional, define claramente su semántica y evita que signifique varias cosas a la vez.
Si una función puede fallar, su tipo de retorno debe hacerlo visible.
Devolver null sin contexto desplaza el problema al consumidor. Es preferible usar un resultado discriminado de éxito/error.
Este patrón mejora testabilidad porque cada rama tiene contrato explícito y assertions concretas.
También reduce excepciones ocultas: el flujo de error queda en la firma y no enterrado en logs o catch genéricos.
Al pasar funciones como argumento, tipar bien la interfaz evita bugs de acoplamiento.
Define tipos de callback reutilizables cuando varios módulos comparten la misma forma de interacción.
Evita any en callbacks: suele ocultar discrepancias entre productor y consumidor de eventos.
Si una función compone otras, declara su retorno explícito para que el pipeline completo sea predecible.