I’ve written previously about how useful I find effect sketches for helping me to understand how an object’s methods and fields fit together and while drawing one a couple of weeks ago I noticed that it’s actually quite useful for seeing which parts of the code will be the easiest to change.

I was fairly sure one of the object’s in our code base was doing too many things due to the fact that it had a lot of dependencies.

However, it wasn’t obvious to me from looking at the code which would be the easiest place to start in pulling out some of those responsibilities.

I therefore drew out an effect sketch which looked something like this:

From the diagram I could see more clearly that 'MethodC' is using 3 fields which are not used by any of the other methods in the object.

This therefore seemed like the perfect method to pull out since I could do so really easily and get rid of 3 of the object’s fields since noone else used them anyway.

This reminded me a lot of the Mikado method for addressing technical debt which I’ve read about but haven’t used yet.

As I understand it, the goal with the Mikado method is to locate areas of the code base that we can change easily because there are no dependencies on this piece of code.

When using effect sketches the goal is to try and use the sketch to work out how we can group functionality and I think the idea of making initial changes that have a low impact is a good one to follow.

I drew my initial effect sketch on paper but I noticed that drawing it up in graphviz actually makes it even more obvious which bits of functionality are related.

For example I hadn’t realised that 'fieldB' was used by so many methods until I typed this up.

It’s quite a neat tool and easy to pick up. This is my 'dot' file for the above sketch:

blog.dot

And to generate a png I ran the following command from the terminal: