Don't Rewrite, Replace

  • Don't change things
    1. add new things (via copy/paste)
    2. migrate the clients
    3. remove old things

-- from Add Fractions in Java Part 2 - The World's Best Intro to TDD, Level 1: TDD Done Right - jbrains.c

  1. Introduce an abstraction around the code that is to be replaced, and commit that for all to see.
  2. Write a second implementation of the abstraction for the to-be-introduced code, and commit that,
  3. Flip the software 'off' switch to 'on' for the rest of the team, and commit/push that.
  4. Remove the to-be-replaced implementation
  5. Remove the abstraction

-- from Branch by Abstraction - Trunk Based Development

This 3-step rule is the safest way I know to change software. Because in every step, we make sure the app still works:

  1. 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.
  2. 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.
  3. 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.

  1. Code-level refactor (i.e. Extract method, extract class, etc.)
  2. Dependency-level replacement (i.e. 3rd-party library switch)
  3. 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