-
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/1380133918754627586
-
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?
-
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:
-
- 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.
-
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.
-
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!
-
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!