4 ms·
I want to try a re-write project at least once in my career. I've been thinking about how I might tackle it: The legacy system components are unlikely to have
by CraigJPerry 11y ago
I want to try a re-write project at least once in my career. I've been thinking about how I might tackle it:
The legacy system components are unlikely to have ideal boundaries (unless you're insanely lucky) due to organic growth. So step 1, identify key boundaries and implement them as libraries / micro services / whatever makes sense.
Step 2, identify the highest value component to refactor - that might not be the part that makes the system go better for the users, it might be tackling the bit generating most support noise so you can free up more dev resource.
Begin the refactoring with a release, the new component begins life as a shim between the component interface and the legacy component, calling out to the legacy component for all features initially but as functionality is migrated to the new component it gradually uses the legacy component less and less.
You can always release at any time and you'll have a system using new code where it's written and falling back to old code where not.
Lather, rinse, repeat.
Key challenges I see during the refactoring are managing state during the refactoring of complex behaviors of the original component. It may lead to a private interface which is more granular but only exposed to the new replacement component.
Interesting stuff for sure.