How to refactor large, HUGE, complex codebases
This is a note to any software developer who is stuck refactoring 100k+ LOC C or Java project, where changing anything at all will break the system.
I came across this method a few years ago and it has been immensely useful to me for any sort of complex project. It was so good that it stuck with me and I completely forgot that other people may not know it. Additionally, searching for “refactoring” on amazon sadly does not bring up this technique in the search results.
The technique and the book describing it is called The Mikado Method. The gist is this: we draw a bubble of what we want to achieve, go at it and if we can’t achieve it we roll back to the last known good state and add a new bubble. It is really simple and illustrated by the diagram above. I encourage your organization to buy the book and read it.
This technique provides numerous advantages not all immediately obvious:
- Your system is always in a good working state
- You focus on one change at a time
- You have a history of changes you made to the project
- The mikado diagram becomes documentation to be shared with others
- You can always start at the leafs — no need to think of what to do next.
Recently, an app called Taskheat (UPDATE: July 16, 2021 — I no longer use Taskheat as I found it cumbersome. I use plain paper instead.) came into existence that allows for the same concept to be expressed on the computer. It may have square “bubbles” and the arrows point in the “wrong” direction but the idea is the same. Here I recreate the diagram from the beginning of the blog post (it is much more finicky to get the arrows pointing the right way here than on paper):
In addition to refactoring, if you have a complex project, you can apply this method to it as well.
I hope this note proves helpful to someone in the future. Good luck!
