-
The process can change a lot depending… - Are frameworks baked-in to everything, or "we needed a date-picker, & used the one from X"? - Is the code already well-organized? - Is this just code refactor, or a full re-design? - What's the tech stack? another 🧵 heathernew09/1380133918754627586Permalink On twitter.com
♻️ 1 Retweets ❤️ 5 Favorites Mood 0
-
First thing is always to plan out where we're trying to end up. What are the tools & conventions we'll need on the other end of the refactor? Where do things live? How will we manage tokens? How will we access components? How do we ensure documentation is baked into the process?Permalink On twitter.com
-
We want to get that basic infrastructure in place asap, running parallel to the old, & continuously integrated w/ the live project. If feature work is happening at the same time, those features should follow the new process whenever possible. Continuous integration is essential:On twitter.com
-
- Everyone is immediately testing out the new tools/processes as part of their normal work flow. We can see issues, & make adjustments as we go. - Long-running forks often get abandoned just because they're hard to merge, or increasingly out-of-sync with new features.Permalink On twitter.com
-
With infrastructure established, we start isolating patterns: design tokens, layouts, themes, visual patterns, specific components, etc… We start with tokens (usually colors) & work our way from broad patterns to narrow details. Some combo of ITCSS layers & Atomic Design.Permalink On twitter.com
-
My favorite token format is in SassCSS, exporting to JSON as needed. Design concepts like "colors" & "lengths" are first-class data types in Sass, which is really useful. But that decision is also influenced by tech stack, who's maintaining the system, etc.Permalink On twitter.com
-
As we go, we like to "patch" (think wiring patch-bay) the new tokens with the old, wherever possible: $ new-token: mediumVioletRed; $ bootstrap-token: $ new-token; New features will use the new token, but old code can too. We're not maintaining entirely separate systems.Permalink On twitter.com
-
Then we're moving one pattern/component at a time, e.g. "buttons". Ideally we can swap out all instances at once, but not always. We like the global systems working in parallel, but we don't really want legacy components hanging around, once the new is in place. Delete!Permalink On twitter.com
-
Rinse & repeat, as long as it takes – until all the old code patterns have been ported to the new system. There are many little variations & caveats throughout - it's never exactly the same from one project to the next. But that's roughly the approach. Hope it's helpful!Permalink On twitter.com