En la era de la AI, el refactoring ya no es trabajo manual tedioso
(blog.lemonbase.team)Este es un artículo sobre cómo organizar el legado de un Design System con AI + Codemod.
Espero que le sirva como referencia a quienes están por enfrentar un refactoring a gran escala.
Contexto del problema
- En el Design System interno, muchos componentes como Typography fueron marcados como deprecated
- Tras introducir un nuevo Design System + Tailwind, quedaron mezclados patrones deprecated dentro de una misma base de código
- Intentar ordenarlo poco a poco con la regla Boy Scout era difícil porque
- había demasiados archivos
- por el principio de separar los PR de cambios funcionales y los PR de refactoring, siempre terminaba bajando de prioridad
Enfoque: Codemod + AI
- En lugar de reemplazo de cadenas, se usó un Codemod basado en AST (jscodeshift)
- Con ayuda de AI se hizo lo siguiente:
- investigación exhaustiva de los patrones de uso de Typography deprecated
- organización de las reglas Before/After
- apoyo para redactar el borrador del script de transformación en jscodeshift y del código de prueba
- Ejemplos clave de transformación:
<Body1 bold>텍스트</Body1>
→<span className="typography-body1-bold">텍스트</span><HeadLine5 as="h1" color={SemanticColor.Text.Primary}>
→<h1 className="typography-headLine5 text-primary">
Resultados
- Aproximadamente el 95% de los patrones deprecated relacionados con Typography se transformaron automáticamente
- Se redujeron mucho los patrones mezclados, mejorando la consistencia del código y la experiencia de onboarding
- Se aseguró la opción de “hacer también con Codemod el próximo reemplazo del Design System”
Aprendizajes
- Más trabajos de refactoring de los que uno imagina pueden automatizarse con AST + Codemod
- En transformaciones automáticas a gran escala, revisar las “reglas de transformación + tests” es más eficiente y seguro que revisar el “diff de archivos”
- Conviene separar los roles: la AI para análisis de patrones y apoyo en borradores, y el Codemod para reemplazos masivos consistentes
6 comentarios
¡Es un artículo muy interesante..!
El código del frontend del proyecto actual está hecho un desastre, así que tendré que probarlo.
Mucho gusto. ¡Gracias por leerlo y disfrutarlo!
Si tienen alguna duda al probarlo, no duden en dejarla en cualquier momento!!
Es un artículo muy útil. Me acordé de cuando sufrí al intentar automatizar todo al principio, al definir las reglas del AST... Al final, te das cuenta de que lo correcto es dejar fuera los casos ambiguos y definir solo lo que es realmente seguro.
Sí, totalmente T_T yo también tuve la experiencia de decir exactamente "¡automaticemos todo!" y terminar pasándola mal.
Tal como comentas, fue más eficiente dejar fuera los casos ambiguos y priorizar primero los patrones claros jaja
Llevarlo así en dos vías terminó siendo lo más eficiente cuando también consideras la implementación, la revisión y hasta el riesgo de bugs.
Oh, esto está bueno.
¡¡Muchas gracias por verlo con buenos ojos!!