Mark Needham

Thoughts on Software Development

Coding: Effect sketches and the Mikado method

with 7 comments

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:

blog.png

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
Be Sociable, Share!

Written by Mark Needham

February 23rd, 2010 at 12:29 am

Posted in Coding

Tagged with

  • 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.

  • 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.

  • Pingback: Linear Way of Thinking « Updates from a continuous developer()

  • 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. =)

  • Pingback: Mentions of the Mikado Method « Home of the Mikado Method()

  • Pingback: Mikado-ish method for debugging at Mark Needham()

  • Pingback: Mikado-ish method for debugging | DotNeter(Asp.NETer)()