El peligro de trivializar. Edición TypeScript.

28 de septiembre de 2024

Recientemente un colega de profesión se ha sorprendido al permitirle usar any en TypeScript. Suelo dar mucho la turra con ello. En la práctica totalidad del código que he auditado rara vez he encontrado algún any justificado en usos “normales”.

El uso justificado de any más habitual que he visto es precisamente el que podemos encontrar en la documentación, traduzco:

❌ No uses any como un tipo salvo que estés en proceso de migrar un proyecto de JavaScript a TypeScript. El compilador tratará el any como “por favor desactiva la revisión de tipos para esto”. Similar a poner un comentario @ts-ignore alrededor de cada uso de la variable. Esto puede ser realmente útil cuando comienzas a migrar un proyecto de JavaScript a TypeScript dado que puedes establecer el tipo de las partes aún no migradas a any, pero en un proyecto full TypeScript estarás desactivando el tipado para cada parte del programa que lo utilice.

Pero, ¿quién decide qué es justificación y qué excusa?, ¿cómo diferencias una negligencia de una decisión deliberada con buena finalidad?

En el repo Type Challenges de Anthony Fu puedes encontrar una gran variedad de desafíos y soluciones de tipado de todos los niveles, donde verás que no en pocas ocasiones se utiliza any en un sentido semántico y justificado, sin implicaciones problemáticas, pero incluso ahí, en la mayoría de casos puede usarse alguna alternativa, muchas veces un simple unknown puede reemplazarlo sin necesidad de narrowing ni nada extra.

Lo mejor no significa lo más práctico

Cuando no tienes conocimientos avanzados de TypeScript y tipar correctamente un caso extraño puede implicar muchas horas, hay que aprender a poner límites a la excelencia.

Tenemos muchas herramientas para minimizar el impacto de la deuda técnica que implica un tipado incompleto, empezando por flexibilizar el tipo y proteger con tests.

No hace falta que haya prisa o se acerque una deadline para tomar estas decisiones, quizás hemos pillado mucho impulso y no queremos pararnos a estar con detalles, por mucho que sea lo correcto, no estamos en el “mood” de hacer esto.

Esto puede ser todavía más crítico durante una fase de diseño donde no está del todo claro la estructura que vamos a tener. Definir tipos muy avanzados y complejos a medida que se trabaja puede impedirnos el posponer decisiones. También puede hacer que tomar decisiones prematuras tenga un impacto mayor en el tiempo invertido si finalmente son descartadas.

Roles y responsabilidades

Hace un año, David Heinemeier Hansson (DHH), creador de Ruby on Rails, generó una fuerte polémica en lo que fue casi entendido como un manifiesto contra TypeScript, explicando cómo abandonaron TypeScript en su proyecto Turbo tras pasar infiernos con él.

DHH señalaba, entre tantas quejas, a la enorme necesidad de usar any que tenían en su proyecto, siendo TypeScript inútil o estando desactivado en la mayoría de casos. Hice una auditoría personal a ese proyecto. Mi conclusión: no lo entendían ni sabían usarlo.

Y no es que yo me considerara un experto en esta tecnología entonces, ni ahora, pero claramente veía el trabajo de personas que la habían trivializado. Muchos seniors creen que TypeScript es una “tontería” para meter tipado y ya, algo que se aprende en minutos.

Entender correctamente sus flujos de análisis y sus características avanzadas no es algo trivial, y casi diría que es muy vocacional: aquellos que disfrutan el tooling y la DX tienen una mayor inclinación natural hacia él.

Al principio uno puede estar horas, y no exagero, dando vueltas a cómo conseguir tipar una estructura de datos sencillita para que tenga coherencia. Quien trivializa considerará que es una tontería que se hace en cinco minutos.

Era evidente que entre el equipo de DHH no había nadie con experiencia avanzada en TypeScript, lo que me sorprende porque el propio DHH decía haber estado cinco años trabajando con él, lo que resalta la necesidad de tener al menos a una persona centrada en la experiencia de desarrollo y profundizar en esto.

JavaScript puede migrarse a TypeScript, y durante un proyecto puede trabajarse con JavaScript o desactivar el chequeo de tipos de algún tipo complejo mientras alguien asume la responsabilidad de revisar y tipar. De este modo, todo el mundo está cómodo en su trabajo y se sigue obteniendo lo mejor de ambos mundos de cara al futuro del proyecto.

Con este enfoque y con el tiempo, el conocimiento de los expertos (habitualmente DX) acaba permeando y transmitiéndose a todo el equipo y poco a poco otros van aprendiendo TypeScript a niveles avanzados, sin forzar nada y sin frustraciones. Eso es más viable que el salto a una piscina vacía como el que veo hacer a tanta gente, comenzando proyectos con TypeScript desde el inicio sin saber utilizarlo.