¿Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible?

Detrás de "¿Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible?" suele haber una tensión real en TypeScript entre depuración y sistema de tipos.

En un nivel intermedio interesa ver si colocas bien los límites de "Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible", justificas por qué eliges ese patrón y explicas cómo lo mantendrías legible para el equipo.

Qué evalúa el entrevistador

• Si distingues qué parte de "Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible" pertenece a depuración y cuál debería resolverse en sistema de tipos.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si separas decisiones reversibles de irreversibles y justificas la arquitectura por velocidad de cambio, no por preferencia personal.

Respuesta sólida

• Empieza por el borde del problema: dominios, módulos o responsabilidades que hoy cambian a ritmos distintos en TypeScript.
• Justifica dónde pondrías las fronteras, qué acoplamientos aceptarías al principio y qué señal te haría revisar la decisión.
• Cierra con un criterio de validación real: coste de cambio, tiempo de entrega, número de puntos tocados o incidencias evitadas.

Compromisos y errores comunes

• Abrir más capas de las necesarias suele esconder la lógica importante y hacer más lenta la entrega sin resolver el acoplamiento real.
• Una arquitectura que nadie del equipo puede explicar en una pizarra rara vez aguanta bien el paso del tiempo.

Ejemplo de código

No se trata de memorizar esta implementación, sino de enseñar cómo ordenar el flujo de depuración en TypeScript sin mezclar responsabilidades ni perder de vista sistema de tipos.

type LoadingState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

function isSuccess<T>(state: LoadingState<T>): state is { status: "success"; data: T } {
  return state.status === "success";
}

const state: LoadingState<number> = { status: "success", data: 42 };
if (isSuccess(state)) console.log(state.data);

En entrevista yo usaría un ejemplo de este tamaño para "Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible": suficiente para demostrar criterio y lo bastante pequeño como para discutir riesgos y variantes sin perderse.

Ejemplo o caso real

Un caso creíble para "¿Qué señales te dicen que un tipo es demasiado complejo para seguir siendo mantenible?" aparece cuando una funcionalidad de TypeScript mezcla depuración con sistema de tipos y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

Si una decisión de TypeScript no mejora claridad, coste de cambio o fiabilidad, probablemente aún no merece existir.