Historias y Estrategias de la Conversión a TypeScript

Hola, y bienvenidos a historias y estrategias de la conversión a TypeScript conmigo, Josh Goldberg.

Para empezar, hola, soy de Upstate New York.

Soy un desarrollador de front-end en el equipo de plataforma web en Code Academy, anteriormente Microsoft,

y soy un papá de gatos.

Mi esposa y yo tenemos algunos gatos.

Son muy lindos.

Todo el contenido de esta presentación está disponible en mi sitio web bajo el enlace de las diapositivas en esta charla en joshuakgoldberg.com.

Esta presentación incluye varias imágenes animadas en bucle.

Si te distraen, te recomendaría verlas en PowerPoint, que te permite pausarlas.

En cuanto a la agenda, primero vamos a hablar sobre Code Academy en 2019 antes de dar el salto a TypeScript, cómo tomamos esa decisión de pasar a TypeScript, algunas de las técnicas que utilizamos para compartir conocimientos en el equipo, los detalles técnicos de lo que hicimos para hacer ese cambio, y luego algunas de las lecciones que aprendimos al final del proceso, cosas que tal vez puedas utilizar en tus conversiones, espero. Buen material.

Comenzando, ¿dónde estaba CodeCademy antes de TypeScript?

Retrocedamos hasta principios de 2019, una época más sencilla.

Teníamos una aplicación principal de front-end, que en ese momento consistía en alrededor de 2,000 archivos de React y Redux, algunos archivos más en un sistema de diseño separado, que en sí mismo se convirtió a TypeScript como prueba de concepto, y la mayoría de los miembros del equipo solo habían oído vagamente hablar de TypeScript.

No había un gran tema o punto de conocimiento en el equipo.

El equipo en sí era bastante pequeño.

Eran solo alrededor de 20, tal vez 30 ingenieros como máximo.

La mayoría de las personas realmente no tenían experiencia con TypeScript y, como en cualquier equipo de ingeniería, había trabajo en curso en torno a características y correcciones de errores.

Entonces, ¿cómo lo hicimos?

¿Cómo hicimos ese cambio a TypeScript?

Primero, tomamos la decisión de que queríamos hacerlo en primer lugar, y cuando hay voluntad, hay una manera, pero tiene que haber voluntad.

Cualquier cambio arquitectónico debe contar con el apoyo informado de sus constituyentes.

Creo que mucha gente, especialmente aquellos que son nuevos en un equipo, cometen el error de tratar de sacar conclusiones de inmediato y empujar una agenda, enviar propuestas, lo cual muchas veces es un error hacerlo de inmediato.

Es una buena idea absorber las experiencias de ser un desarrollador en el equipo, hablar con la gente, tener una idea de cuáles son los problemas reales, y luego utilizar eso para informar tus decisiones sobre qué impulsar y cómo.

No me malinterpretes.

No estoy tratando de menospreciar el hecho de entrar en un equipo con una perspectiva fresca e intentar hacer que la gente entienda y escuche esa perspectiva.

Eso es genial.

Eso es encomiable.

Los equipos definitivamente deberían estar abiertos a que llegues con ideas frescas, pero esas ideas frescas y perspectivas tienen muchas más posibilidades de tener éxito si las validas con quienes te rodean, si puedes convencer a las personas de su validez.

Así que no seas un malcriado.

Definitivamente habla con la gente antes de intentar presionarlos para que hagan cosas.

Si realmente quieres presionar a la gente para que haga cosas, te recomiendo encarecidamente que crees algún tipo de ambiente emocionante para ello.

Si hay algún cambio que quieras hacer, como TypeScript, quieres que la gente lo sienta.

Deberían estar emocionados en sus huesos.

Esto es increíble. Esto va a hacer mi vida más feliz y mejor, el código va a funcionar, va a ser increíble, quiero hacerlo. Esa es la sensación que quieres transmitir con algunas de las decisiones más importantes que quieres impulsar en el equipo.

Parte de la forma en que lo hicimos fue alentar a las personas a pensar en cómo TypeScript ayuda a sus objetivos existentes, siempre es una buena idea. Mi imagen favorita de la fase de evangelización de nuestra versión de TypeScript al comienzo fue anunciarlo como parte del embudo de adquisición de errores, como lo llamamos, o el antifunnel. No dibujado a escala ya que no hay una escala confiable aquí. Ninguna parte de esto, ya sea la revisión de código o lo que sea, puede prevenir realmente todos los errores, pero juntos pueden ayudar a reducir los errores y los bloqueos en los sitios. Eso fue una gran parte del plan del equipo a principios de 2019, algo en lo que queríamos mejorar, la estabilidad, no tener errores y peculiaridades molestas. TypeScript es una de las características principales de TypeScript, y te ayuda a encontrar errores temprano.

Entonces, una vez que decidimos hacerlo, necesitamos preparar al equipo. Compartir conocimientos, como ellos lo llaman. Esto fue especialmente valioso antes de tomar la decisión, donde queríamos que las personas entendieran lo que significaba para que pudieran contribuir de manera significativa a la conversación. Identificamos aproximadamente dos arquetipos de personas en el equipo. En primer lugar, teníamos a los expertos en el área, alguien como yo que ya está muy emocionado y familiarizado con TypeScript. Puedo decirlo. Son el tipo de persona que puedes usar para informar al equipo sobre la tecnología, introducir mejores prácticas, explicarla a los demás, establecer los materiales de aprendizaje adecuados. Son la persona que puede salvar al equipo de sí mismos, evitando caer en los errores obvios que tú conoces por haberlo hecho antes. También son útiles y muy valiosos en el equipo los animadores, personas que pueden no tener tanta experiencia con, digamos, TypeScript, pero que aún están muy emocionados y quieren impulsarlo y están de acuerdo con ello. Estas son las personas que pueden actuar como conejillos de indias, que lo probarán, tus primeros adoptantes o probadores beta, como los llaman. Pueden ayudar a difundirlo entre el equipo de manera mucho más efectiva que tú, porque hay muchos de ellos, a menudo, si la decisión es emocionante y nueva. Así que recomiendo tratar de tener al menos uno o dos animadores por área del equipo para que puedan difundir la alegría de la nueva cosa entre el área del equipo. Al menos en Codecademy y muchas otras empresas que he visto, los equipos de producto tienden a hablar mucho entre sí. Así que si puedes tener al menos una persona en esa mezcla, eso es muy útil para introducir una nueva tecnología. Para los expertos en el área, es útil tener al menos dos, porque si solo tienes uno, no tienen un compañero que realmente pueda validar lo que están haciendo, al menos desde la experiencia previa. Así que es útil tener al menos dos que puedan intercambiar ideas entre ellos.

Parte del intercambio de conocimientos para nosotros, una vez que identificamos a los responsables del área y a los animadores, fueron las presentaciones internas porque nadie hace nada hasta que haya una charla que explique la idea general, el espíritu del movimiento del equipo hacia ella. Realizamos dos charlas informales, que tu equipo podría llamar charlas de tiza o charlas de almuerzo o algo similar presentaciones.

La primera fue el análisis estático en Javascript. Fue una introducción general al concepto de analizar el archivo sin ejecutar y descubrir qué está mal o bien en él. Y honestamente, ni siquiera hablamos tanto de TypeScript. Fue principalmente sobre las herramientas existentes que ya estábamos usando para que las personas se pusieran en el estado mental correcto, principalmente las más tempranas.

Después de eso, tuvimos la charla realmente emocionante, cuando estaba feliz por TypeScript, que fue específicamente sobre qué es TypeScript y cómo se verían las características que usaríamos. También participamos en las charlas relámpago existentes del equipo, que eran una serie de unas pocas personas hablando cada semana, alrededor de cinco minutos, sobre cualquier tema aleatorio. Estas fueron particularmente útiles para los temas más esotéricos de TypeScript que podrían ser interesantes o lindos pero no del todo útiles para la mayoría de las personas que intentan decidir si usarlo o adoptarlo. Las presentaciones son realmente útiles porque las personas pueden verlas después y repasar el contenido.

Las interacciones individuales más valiosas, creo, fueron emparejarse con personas porque nadie realmente aprende algo hasta que se ve obligado a hacerlo, al menos en mi experiencia. Y la generalización fue útil. Al menos para mí, si no he escrito un lenguaje o no he usado un marco de trabajo, no realmente lo entiendo hasta que lo hago. Así que programé al menos una sesión de emparejamiento con cada miembro del equipo enfocado en el frontend, que en ese momento eran alrededor de una docena, un poco más. En estas sesiones, nos emparejábamos, uno codificaba en TypeScript y el otro supervisaba. No fue escalable. Intentaría hacerlo ahora que el equipo es de más de 50-60 personas. Eso sería realmente doloroso. Pero en ese momento, fue útil y creo que fue una de las formas más importantes y relevantes de incorporar a las personas a TypeScript. Lo recomiendo encarecidamente, especialmente si puedes ampliarlo con más responsables del área.

En cuanto a los detalles técnicos, los cambios de código literales que hicimos, los mantuvimos al mínimo posible. Y esta es una estrategia que recomendaría encarecidamente para cualquier conversión a TypeScript. No quieres empezar con una solicitud de extracción de varios miles de archivos que convierta todo bajo el sol. Eso es muy fácil de romper y muy difícil de ajustar para conflictos de fusión. Así que comenzamos con la conversión mínima de las integraciones de infraestructura con solo unos pocos archivos, convirtiéndolos a TS o TSX, solo para asegurarnos de que funcionara. Esto fue bueno por varias razones. En primer lugar, la solicitud de extracción inicial no interrumpió al equipo en absoluto. No tuvimos que detener las implementaciones ni nada para avanzar. Tampoco cambiamos mucho a las personas con eso. Nadie se vio afectado por ello.

Pudimos esperar para presentar TypeScript a las personas hasta que fuera el momento adecuado, hasta que pudiéramos emparejarnos con ellos o hasta que ya se sintieran más cómodos con las ideas. Y, sinceramente, la infraestructura no fue un cambio tan grande en esta solicitud de extracción. Prácticamente todo lo que usamos ya tenía una inclusión básica de TypeScript, ya sea incorporada o algo que se puede obtener fácilmente en línea. Nuestro ejecutor de pruebas y nuestro constructor de producción, Justin Roepack, respectivamente, tenían dependencia de Babel para compilar el código, y Babel tiene un conjunto de ajustes de TypeScript realmente bueno, el conjunto de ajustes de Babel para TypeScript. Así que simplemente lo usamos y funcionó como por arte de magia. ESLint tiene TypeScript ESLint, un proyecto al que a veces contribuyo, por lo que estoy bastante familiarizado con él, y también funcionó muy bien. Las ejecuciones de ESLint nos llevan un poco más de tiempo porque incluimos el verificador de tipos, y eso está bien. Aún así, todo funciona. Curiosamente, Prettier ni siquiera tiene un paso de configuración que necesitáramos usar. Simplemente admite TypeScript automáticamente de forma nativa. Esa fue mi parte favorita. No tuvimos que hacer nada al respecto. Fue genial.

Una vez que introdujimos TypeScript en el sistema de compilación, priorizamos la facilidad de adopción en lugar de hacer todo de forma rápida y repentina en TypeScript. Así que tratamos de no ser demasiado disruptivos para las personas. Exclusivamente usamos TypeScript como una sintaxis y un verificador de tiempo de compilación. No lo utilizamos para verificar código JavaScript o cosas existentes que no eran TypeScript. No queríamos interrumpir a los ingenieros con mensajes sobre código heredado que aún no estaba destinado a ser TypeScript. Por lo tanto, no había necesidad de verificar JS, como se llama la opción del compilador.

Tampoco activamos la configuración del compilador 'no implicit any', que es muy útil, desafortunadamente. Es difícil en una base de código mixta de TypeScript y JavaScript. Si un archivo importa desde un archivo JavaScript y quieres convertirlo a TypeScript, entonces a veces tienes que convertir todas sus dependencias para configurar correctamente esos tipos. Y eso es simplemente molesto. Terminamos utilizando un proceso similar más adelante para convertir gradualmente los archivos en 'null implicit any'.

Por otro lado, sí pudimos habilitar fácilmente las comprobaciones estrictas de nulos desde el principio. Un concepto muy simple, no considerar nulo y indefinido como asignables a otros tipos. Y fue muy útil. Así que sí, lo obtuvimos desde el principio. Maravilloso.

A medida que avanzábamos en el tiempo, adoptamos una estrategia de solicitudes de extracción dedicadas, en su mayor parte, para convertir a TypeScript. Ocasionalmente, un miembro del equipo se emocionaba y convertía algo a TypeScript como parte de una solicitud de extracción existente, pero en su mayor parte, simplemente convertíamos áreas a TypeScript. Esto nos permitió enfocarnos en áreas específicas y centrar esas solicitudes de extracción solo en TypeScript, lo que hacía un poco más claro cuáles eran los cambios. En la mayoría de los casos, o muchos casos, no hubo cambios reales en tiempo de ejecución. Y nos ayudó a comprender qué ingenieros involucrar según las áreas de propiedad.

Esto también fue una gran oportunidad de aprendizaje para la mayoría del equipo. En cada una de estas solicitudes de extracción, explicamos todas las nuevas piezas potencialmente confusas de sintaxis con comentarios en la solicitud de extracción, agregamos un tipo aquí porque, etc. Luego, cuando las personas revisaban las solicitudes de extracción, casi instintivamente tenían que leer estos comentarios, lo cual fue bastante agradable. Así que recomiendo encarecidamente las solicitudes de extracción dedicadas como una forma de ayudar a compartir conocimientos después de la colaboración.

Más adelante, escribí un pequeño script que ejecutaba el comando Git checkout en cada uno de nuestros commits antiguos y verificaba los archivos JS versus los archivos TS para ver cuál era el lenguaje de cada uno. Como puedes ver, con el tiempo, imprime el crecimiento porcentual, lo cual fue bastante ingenioso. Comenzamos la conversión el 2 de abril de 2019, al día siguiente de nuestro lanzamiento del 1 de abril, que fue un curso de código de leyes completamente funcional, que es un lenguaje de programación basado en el uso de Internet y gatos, uno de mis favoritos. La conversión nos llevó aproximadamente 259 días hasta el 17 de diciembre, lo cual está bien. Si hubiéramos querido, podríamos haber priorizado movernos más rápido, pero queríamos optimizar la velocidad. Lo siento, la lentitud, la comodidad sobre la velocidad, algo que recomiendo encarecidamente. No asumas que tienes que pasar a TypeScript de inmediato. Es probable que puedas convertir parte de tu base de código, áreas de alto valor, antes como una forma de prepararte para más adelante.

Mi parte técnica favorita fue Typestep, que es una herramienta que escribí que aplica automáticamente conversiones deducibles o evidentes en masa. Por ejemplo, si un componente de React declara sus prop types con el paquete properties, a veces puedes crear automáticamente un tipo o interfaz de TypeScript solo con mirar el archivo. Es una herramienta bastante involucrada. Aún está en una etapa temprana, tiene muchos errores, pero es de código abierto. Recomiendo encarecidamente echarle un vistazo si quieres usar algo similar para tus conversiones de tipos. Me llevó muchas horas escribirlo, pero nos está ahorrando mucho tiempo hasta el día de hoy para nuestras conversiones. Así que estoy bastante satisfecho con ello. Probablemente podría dar una charla completa, pero no tenemos el tiempo ni el enfoque para esta ocasión. Este es un ejemplo para reiterar, si usas prop types, podríamos leer tu archivo y escribir un script que analice el texto para comprender qué tipo de prop es, es una lista de props y para cada uno de ellos, cuál es el tipo. Y luego podrías imprimir de vuelta al archivo la representación de TypeScript de eso. Es un poco más complicado para los componentes que no declaran sus prop types propias. Tienes que usar el comprobador de tipos para encontrar todas las referencias al componente para ver qué tipos y nombres tienen todas las props proporcionadas en todas esas referencias, y luego combinar todo eso, que es algo que hace Typestat.

Entonces, nuevamente, un poco más complicado, pero aún factible. Así que piensa en los casos extremos y observa Typestat si estás interesado. De todos modos, aprendimos mucho y quedé muy satisfecho con el proceso. Así que me gustaría compartir eso contigo ahora, si está bien. Para empezar, automatiza todo y cualquier cosa siempre que sea posible. Ya sea una configuración realmente compleja como Typestat o simplemente un pequeño script de bash o Node que escribas para hacer el 70% del trabajo obvio. Nos apoyamos en esto para la gran mayoría de los cambios. Mis PR favoritas, las más fluidas, se generaron con Typestat para el 80 al 90% del trabajo, y luego las ajustamos a mano para que fueran correctas. Verificar dos veces. Quiero decir, ¿por qué hacer cosas cuando puedes escribir un script para hacerlo por ti? Además, solo por trabajar con ingenieros, recomiendo encarecidamente configurar una guía de estilo y aprender qué preguntas harían las personas de manera preventiva. Preguntas como, ¿deberías usar una interfaz o un tipo? ¿Cómo declaras las props de React? ¿Qué significa este error común y confuso? Eso se va a preguntar. Se preguntará una y otra vez y desde el principio, así que sé proactivo. Habla con las personas con anticipación y averigua qué es lo que realmente necesitas cubrir y que te preguntarán repetidamente. Una guía de estilo es una excelente manera de responder muchas de estas preguntas y tener una sección de preguntas frecuentes al final. Definitivamente aprendimos de la manera difícil y lo siento si eres un usuario de Code Academy en 2019 y rompimos este sitio o agregamos un error para ti. No conviertas y cambies al mismo tiempo. Cualquier PR importante que cambie toda un área de TypeScript es algo difícil de revisar y es especialmente difícil si también introduces cambios en tiempo de ejecución. Así que recomiendo encarecidamente mantenerlos separados. Si ves un cambio que realmente quieres hacer para TypeScript, simplemente anótalo, guárdalo para más tarde. Resiste la tentación. Sé compasivo incluso en tu revisión de código o para alguien que ahora tiene que pasar por tu PR y QA cambios además de tal vez aprender TypeScript. Eso es un gran desafío. Muchos ingenieros, especialmente en relación con TypeScript, no les gusta tomar atajos. No les gustan los atajos intelectuales. Debería decir. No les gusta hacer las cosas de manera incorrecta. Los ingenieros de TypeScript tienen esta fobia de escribir la palabra any porque piensan que eso hace que el código sea menos bueno. Tal vez solo tengas que hacer una conversión a any, como estábamos usando Redux, lo cual está bien. Redux por sí solo es un sistema hermoso y muy compatible con el sistema de tipos. Pero cuando tienes todas estas integraciones, como nosotros, acciones de Redux, doggos, thunks, se vuelve realmente difícil escribir los tipos.

Nos llevó meses de trabajo en segundo plano llegar a la misma versión de typings para Redux debido a todas las extrañas dependencias interconectadas. Y aún convertimos gran parte de nuestro código de Redux en TypeScript porque simplemente no tenemos tiempo o interés en hacerlo al 100% correctamente. Así que simplemente convierte, está bien. La elección entre convertir y no convertir a TypeScript debería ser bastante clara, simplemente conviértelo y guárdalo para más tarde. Opiniones.

Por último, celebra tus victorias. Gastamos un poco del presupuesto de la oficina en esta tarta y fue algo divertido para el ánimo de, oh, hicimos algo genial. Convertimos a TypeScript. Terminamos. Y fue en diciembre. Ayuda a señalar al equipo cuando haces algo lindo y memorable al final. Recomiendo encarecidamente hacer un gran evento al respecto. Si el tren de la emoción, como podrías haberlo llamado, termina su viaje, celebra su llegada a la estación como una analogía. Irónicamente, creo que la tarta era de vainilla al final.

De todos modos, aquí tienes algunos recursos que podrían ser útiles para ti. El sitio web TypeScriptland.org. Un saludo a nuestro amigo, Orta, es realmente bueno. Tiene mucha documentación excelente, explica muchas cosas buenas sobre TypeScript. Puede ayudarte como nuevo implementador, usuario experimentado o convertidor. De hecho, terminamos escribiendo un curso sobre TypeScript, en el que ayudé como co-líder en la concepción, CodeCademy.com, aprende TypeScript. Lo recomiendo mucho, soy un gran fan. Y luego cada una de las integraciones que mencioné, la guía de Babelius Lynch para webpack tiene su propia guía para usar TypeScript porque es muy popular. Así que recomiendo encarecidamente visitar esos recursos. De todos modos, gracias por escucharme. He estado respondiendo preguntas en el chat a medida que surgen. Y siempre puedes enviarme un tweet o ver mi información de contacto en mi sitio, ambos son joshuakagleberg. Gracias. Que tengas un excelente resto de la conferencia y muchas gracias a los organizadores de la conferencia.