Mikado Re-factoring

I came across the article for large scale re-factoring on InfoQ.

I was really amazed how people can inspire methodologies from real world activities. I remember playing Mikado ( we used to call it something else, I can’t remember) during my school days. Then, it was just a game, now it makes a world of sense in the software world.

I have come across many people, who even after years of experience in the industry, they are scared to do some re-factoring. There are always two reasons to it,

• The code is so messed up, they don’t want to go through the pain of re-factoring it.
• There was not enough tests, that becomes the safety-net when someone is trying to re-factor. (No one wants to be in the bad books of their bosses by breaking the Build )

For the people who fall into the former category, Re-factoring approaches will help them feel more comfortable . Few of the re-factoring approaches are listed here. I always use divide and conquer approach for most of the scenarios that I face on the work.

One such approach is Mikado. Where you define your re-factoring goal using a graph and find the dependencies, till you reach the leaf node. Once you reach the leaf node, You can start re-factoring from the leaves, till you reach the goal. It makes a lot of sense to me. Here is how Mikado works,

The double lined node is the re-factoring goal. To read more on the mikado approach read up on prag-prog (Awesome resource).

Like Mikado? Read more by downloading this book

Advertisement