Im Zeitalter von AI ist Refactoring keine stupide Fleißarbeit mehr
(blog.lemonbase.team)Ein Artikel darüber, wie mit AI + Codemod Legacy in einem Design System aufgeräumt wurde. Ich hoffe, er ist hilfreich für alle, die vor einem groß angelegten Refactoring stehen.
Hintergrund des Problems
- Im unternehmensinternen Design System wurden viele Komponenten wie Typography als Deprecated markiert
- Nach der Einführung des neuen Design Systems + Tailwind existierten Deprecated-Muster innerhalb derselben Codebasis nebeneinander
- Um sie nach der Boy-Scout-Regel nach und nach aufzuräumen, war es
- zu viele Dateien
- und wegen des Prinzips, PRs für Funktionsänderungen und Refactoring-PRs zu trennen, rutschte das Thema in der Priorität immer weiter nach hinten
Vorgehensweise: Codemod + AI
- Verwendet wurde kein String-Replacement, sondern ein AST-basierter Codemod (jscodeshift)
- AI wurde genutzt für:
- eine vollständige Untersuchung der Deprecated-Typography-Nutzungsmuster
- die Aufbereitung der Before/After-Regeln
- Unterstützung beim Schreiben des ersten Entwurfs des jscodeshift-Transformationsskripts und des Testcodes
- Zentrale Transformationsbeispiele:
텍스트→텍스트→
Ergebnis
- Deprecated-Muster rund um Typography wurden zu etwa 95 % automatisch transformiert
- Gemischte Muster wurden deutlich reduziert, was die Konsistenz des Codes und das Onboarding-Erlebnis verbessert hat
- Die Option wurde geschaffen, auch „den nächsten Austausch des Design Systems per Codemod durchzuführen“
Erkenntnisse
- Deutlich mehr Refactoring-Arbeit als gedacht lässt sich mit AST + Codemod automatisieren
- Bei groß angelegten automatischen Transformationen ist ein „Review der Transformationsregeln + Tests“ effizienter und sicherer als ein „Review der Datei-Diffs“
- Es ist sinnvoll, die Rollen zu trennen: AI für Musteranalyse und Unterstützung beim Entwurf, Codemod für konsistente Massenersetzungen
6 Kommentare
Ein wirklich sehr interessanter Artikel..!
Der Frontend-Code des aktuellen Projekts ist im Moment ein ziemliches Chaos, das sollte ich wohl mal ausprobieren!
Freut mich. Vielen Dank, dass Sie den Artikel mit Interesse gelesen haben!
Wenn Sie beim Ausprobieren Fragen haben, hinterlassen Sie jederzeit gern einen Kommentar!!
Ein sehr nützlicher Artikel. Als ich die AST-Regeln festgelegt habe, habe ich anfangs versucht, alles zu automatisieren, und mich dabei ziemlich abgemüht ... Je länger ich daran gearbeitet habe, desto mehr wurde mir klar, dass es am besten ist, die unklaren Fälle auszuklammern und nur die eindeutigen festzulegen.
Stimmt, ich habe auch dieselbe Erfahrung gemacht, als ich dachte: "Lasst uns alles automatisieren!" – und dann ziemlich gelitten habe.
Wie du gesagt hast, war es effizienter, die unklaren Fälle auszuklammern und zuerst die eindeutigen Muster zu bearbeiten, haha.
Diesen Two-Track-Ansatz zu wählen, war unter Berücksichtigung von Implementierung, Review und Bug-Risiko letztlich am effizientesten!
Oh, so etwas ist gut.
Vielen Dank für Ihre positive Einschätzung!!