À l’ère de l’IA, le refactoring n’est plus une corvée

Voici un article sur le nettoyage d’un legacy de Design System avec AI + Codemod. J’espère qu’il pourra être utile à celles et ceux qui s’apprêtent à mener un refactoring à grande échelle.

Contexte du problème

• Dans le Design System interne, de nombreux composants comme Typography ont été dépréciés
• Après l’introduction du nouveau Design System + Tailwind, des patterns dépréciés coexistaient dans une même codebase
• Les nettoyer petit à petit avec la règle du Boy Scout était difficile, car
  • il y avait beaucoup trop de fichiers
  • à cause du principe de séparation entre les PR de changement fonctionnel et les PR de refactoring, la priorité était sans cesse repoussée

Approche : Codemod + IA

• Utilisation d’un Codemod basé sur l’AST (jscodeshift) plutôt qu’un simple remplacement de chaînes
• Utilisation de l’IA pour :
  • recenser de manière exhaustive les patterns d’usage de Typography dépréciés
  • formaliser les règles Before/After
  • aider à rédiger un premier jet du script de transformation jscodeshift et du code de test
• Exemples clés de transformation :
  • 텍스트 → 텍스트
  • →

Résultat

• Environ 95 % des patterns dépréciés liés à Typography ont été convertis automatiquement
• La réduction importante des patterns mixtes a amélioré la cohérence du code et l’expérience d’onboarding
• L’équipe a désormais l’option de se dire : « le prochain remplacement du Design System se fera aussi avec un Codemod »

Ce qu’on en a retenu

• Bien plus de tâches de refactoring qu’on ne l’imagine peuvent être automatisées avec AST + Codemod
• Pour les transformations automatiques à grande échelle, la revue des « règles de transformation + tests » est plus efficace et plus sûre que la revue des diff fichier par fichier
• Il est préférable de distinguer les rôles : l’IA pour l’analyse des patterns et l’aide au brouillon, le Codemod pour les remplacements massifs et cohérents

[hebu570]

C’est un article vraiment très intéressant..!
Le code front de notre projet est actuellement dans un état catastrophique, donc il va falloir qu’on essaie !

[whatsup]

Ravi de vous rencontrer. Merci de l’avoir lu avec plaisir !
N’hésitez pas à laisser un message à tout moment si vous avez des questions en l’essayant !!

[shincad]

Un article très utile. Ça m’a rappelé la galère quand j’ai essayé d’automatiser entièrement la définition des règles AST au début… À force, je me suis rendu compte que la bonne approche était d’exclure les cas ambigus et de ne définir que ce qui est vraiment sûr.

[whatsup]

Oui, tout à fait, bouhouhou… J’ai moi aussi vécu la même galère après m’être dit : « Essayons de tout automatiser ! »
Comme vous l’avez dit, il était plus efficace d’exclure les cas ambigus et de traiter en priorité les patterns clairement identifiés, haha.

• patterns clairs : Codemod
• patterns ambigus : traitement manuel

Avancer ainsi sur deux pistes, en tenant compte des risques d’implémentation, de review et de bugs, s’est révélé plus efficace !

[aliveornot]

Oh, c'est bien ce genre de chose.

[whatsup]

Merci beaucoup pour votre appréciation !!