- Win you the trust and respect of your teammates, before attempting any major rewrite
- Project level refactoring should not go in parallel with day-to-day requirments dev. Use a mock refactoring to discover potential depenedency problem, and refactoring them in day-to-day devs. Finally, halt dev for 2-3 days and focus on project refactoring.
- Refactoring rarely-changed code gives little benefit and most likely doesn’t outweigh the cost. Espcially a lot of such legacy codes are hard to maintain and extend.
- Refactor as little as possible (change ONLY what you need), and unit test is basis for refactoring
- starting very coarse-grained end-to-end test, and gradually add more, finer-grained tests. End-to-end, integration, then unit tests, in that order.
- don’t start making changes until you have a suite of tests that can spot behavior changes. There are times when things that appear to be bugs are actually weird features that the business needs to function.
- Focus more on the user scenario than code logic
7. To solve branch conflicts, use feature flag to hide development in progress
8. Open to extension, close to changes, because changing existing code is easy to introduce new bug
9. Refactor code to be extended, let existing unit tests cover that (only change code), and then enhance with TDD (only add code)
10. Refactoring across services is hard. Options:
- Don’t do it - perfectly valid
- One big version change
- Long term ownership can’t be ambigious. Build a temp team to build the third service - Conway’s law