¿Qué smells ves en una code review TypeScript antes de que exploten en runtime?

Detrás de "¿Qué smells ves en una code review TypeScript antes de que exploten en runtime?" suele haber una tensión real en TypeScript entre depuración y revisión de código.

En un nivel intermedio interesa ver si colocas bien los límites de "Qué smells ves en una code review TypeScript antes de que exploten en runtime", 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é smells ves en una code review TypeScript antes de que exploten en runtime" pertenece a depuración y cuál debería resolverse en revisión de código.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si eres capaz de reproducir, observar y acotar el problema antes de tocar código o antes de pedir una reescritura mayor.

Respuesta sólida

• Empieza haciendo observable el problema: pasos de reproducción, datos de entrada, logs, métricas o test que fallen por una sola causa.
• Reduce el alcance antes de corregir: cambia una variable cada vez y confirma si el fallo está en el código, en el contrato o en el entorno.
• Termina con prevención: una prueba útil, mejor observabilidad o un diseño más simple que haga menos probable la recaída.

Compromisos y errores comunes

• Corregir una incidencia sin dejar rastro observable o sin una prueba asociada suele invitar a la repetición del mismo fallo con otra forma.
• Un test que solo replica la implementación deja tranquilidad aparente, pero poca señal cuando el comportamiento importante cambia.

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 revisión de código.

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é smells ves en una code review TypeScript antes de que exploten en runtime": suficiente para demostrar criterio y lo bastante pequeño como para discutir riesgos y variantes sin perderse.

Ejemplo o caso real

Yo lo bajaría a un escenario reconocible de TypeScript: una pieza donde "Qué smells ves en una code review TypeScript antes de que exploten en runtime" aparece de forma recurrente, ya ha dejado señales en revisión o en soporte y mezcla depuración con revisión de código. Si la decisión mejora claridad, observabilidad y velocidad de cambio en ese trozo, entonces merece escalarla; si no, la dejaría local y documentada.

Frase corta de entrevista

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