Coding: Effect sketches and the Mikado method
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
digraph effectgraph {
size="8,8";
"MethodA" -> "fieldA";
"MethodA" -> "fieldB";
"MethodA" -> "fieldC";
"MethodB" -> "fieldB";
"MethodB" -> "fieldE";
"MethodB" -> "fieldF";
"MethodC" -> "fieldG";
"MethodC" -> "fieldH"
"MethodC" -> "fieldD"
"MethodD" -> "fieldB"
"MethodD" -> "fieldI"
}And to generate a png I ran the following command from the terminal:
dot -Tpng -blog.png blog.dot
Thanks for the link to the Mikado method.
I found a query in NDepend that looks for types that aren't cohesive. They describe it here:
http://www.ndepend.com/Metrics.aspx#LCOM
It's not quite the same because this identifies types and not methods, but it might get you close enough.
Perhaps a small tool that uses NRefactory could parse your source and generate dot files so that you don't have to do it by hand.
Jason Diamond
23 Feb 10 at 1:45 am
I haven't used Refactory before, gonna have a look at that. I think you're probably right though – there is certainly some benefit in drawing it out by hand but perhaps the time it takes to do that is outweighed by what you could do with a tool.
Mark Needham
23 Feb 10 at 1:53 am
[...] remember K most of the time, the starter, but then all becomes complicated. Thanks to Mark's blog on sketches, and Graphviz group at AT&T. My graph is not depending on real data, but I tried to make it [...]
Linear Way of Thinking « Updates from a continuous developer
23 Feb 10 at 8:20 am
I've used NRefactory to parse C# source files before. It's not well documented, but it was easy enough to figure out. I got the DLLs from SharpDevelop since it doesn't seem to have a project of its own that I could find.
While playing around with NDepend 3′s new Visual Studio integration, I found that you could right-click on any class and select "View internal dependencies on graph". It shows both method and field dependencies, so it can get much busier than the graph you created, but it's still very convenient.
I promise I'm not an NDepend salesman. =)
Jason Diamond
23 Feb 10 at 10:21 pm
[...] http://www.markhneedham.com/blog/2010/02/23/coding-effect-sketches-and-the-mikado-method/ [...]
Mentions of the Mikado Method « Home of the Mikado Method
5 Jun 10 at 8:47 pm
[...] written previously about the Mikado method and how I've made use of it for identifying ways in which… but I think this approach is more generally applicable for any kind of code [...]
Mikado-ish method for debugging at Mark Needham
4 Jul 10 at 1:21 am
[...] written previously about the Mikado method and how I've made use of it for identifying ways in… but I think this approach is more generally applicable for any kind of code [...]
Mikado-ish method for debugging | DotNeter(Asp.NETer)
5 Jul 10 at 5:04 am