Na era da IA, refatoração não é mais trabalho braçal
(blog.lemonbase.team)Este é um texto sobre como organizar o legado de um Design System com AI + Codemod.
Espero que sirva de referência para quem está prestes a enfrentar uma refatoração em larga escala.
Contexto do problema
- No Design System interno, vários componentes como Typography foram marcados como deprecated
- Após a introdução do novo Design System + Tailwind, padrões deprecated passaram a coexistir na mesma base de código
- Para ir limpando aos poucos pela regra do Boy Scout,
- havia arquivos demais
- e, por causa do princípio de separar PRs de mudança funcional e PRs de refatoração, isso continuava sendo empurrado para baixo na prioridade
Abordagem: Codemod + IA
- Em vez de substituição de strings, foi usado Codemod baseado em AST (jscodeshift)
- Usando IA para:
- fazer um levantamento completo dos padrões de uso da Typography deprecated
- organizar as regras de Before/After
- ajudar a escrever o rascunho do script de transformação em jscodeshift e os códigos de teste
- Exemplos centrais de transformação:
<Body1 bold>텍스트</Body1>
→<span className="typography-body1-bold">텍스트</span><HeadLine5 as="h1" color={SemanticColor.Text.Primary}>
→<h1 className="typography-headLine5 text-primary">
Resultados
- Cerca de 95% das patterns deprecated relacionadas a Typography foram convertidas automaticamente
- A redução dos padrões mistos melhorou bastante a consistência do código e a experiência de onboarding
- Foi garantida a opção de dizer: “a próxima troca de Design System também será feita com Codemod”
Lições aprendidas
- Mais trabalhos de refatoração do que se imagina podem ser automatizados com AST + Codemod
- Em conversões automáticas em larga escala, revisar “regras de transformação + testes” é mais eficiente e seguro do que revisar “diffs de arquivos”
- É melhor separar os papéis: a IA como apoio para análise de padrões e criação de rascunhos, e o Codemod para substituições consistentes em grande volume
6 comentários
Texto muito interessante..!
O código de front-end do projeto atual está uma bagunça, então acho que vou ter que experimentar!
Prazer em conhecê-los. Obrigado por lerem com interesse!
Se surgirem dúvidas enquanto forem adotando, deixem uma mensagem a qualquer momento!!
Texto muito útil. Na hora de definir regras de AST, lembro que no começo tentei automatizar tudo e acabei penando... No fim, conforme você vai fazendo, a resposta é deixar de fora os casos ambíguos e definir só o que é realmente certo.
Isso mesmo T_T eu também passei pelo sufoco de tentar fazer exatamente a mesma coisa, tipo "vamos automatizar tudo!".
Como você comentou, foi mais eficiente excluir os casos ambíguos e priorizar primeiro os padrões claros hahaha
Levar dessa forma em duas frentes acabou sendo mais eficiente quando se considera implementação, revisão e até o risco de bugs!
Ah, isso é ótimo.
Muito obrigado pela consideração!!