Don't Rewrite, Replace
- Don't change things
- add new things (via copy/paste)
- migrate the clients
- remove old things
- Introduce an abstraction around the code that is to be replaced, and commit that for all to see.
- Write a second implementation of the abstraction for the to-be-introduced code, and commit that,
- Flip the software 'off' switch to 'on' for the rest of the team, and commit/push that.
- Remove the to-be-replaced implementation
- Remove the abstraction
This 3-step rule is the safest way I know to change software. Because in every step, we make sure the app still works:
- Add a new thing
- If no client is using the new thing, adding it won't affect any of our old code.
- If the adding action is also "safe", the existing behaviour won't change in any way.
- Migrate the clients
- We can migrate the clients one by one. And after each migration, we run the tests and deploy the new tested version.
- We repeat this process until all clients have been migrated.
- Remove the old thing
- Then, since no client is using the old thing, removing it won't affect any behaviour.
- If the removing action is also "safe", the existing behaviour won't change.
And this rule can be applied in various scales of development activities.
- Code-level refactor (i.e. Extract method, extract class, etc.)
- Dependency-level replacement (i.e. 3rd-party library switch)
- Application-level upgrade (i.e. replace a microservice)
This rule is also the core idea behind Refactoring: Improving the Design of Existing Code, and that's why this book is so valuable. Learn this rule to change your app in a controllable way. Happy Hacking!
EDIT: If I've learned this rule before, I would be much more confident when facing the two problems in Learn Incremental Deployment the Hard Way - dsdshome