Most of the time, we have a flat view of our code. We open a file and look and all we see are classes and methods. What we miss is what has been happening to them lately.
We can look through version control logs, but that, again, only gives us a small view. There are things we could miss. For instance, are there methods that, in the haphazard dance of update by multiple committers are never reduced in length?
A while back, I decided to write some code to help me figure this out in Ruby:
To be fair, this only a small part of it.
What I've done is ripped through the git log of a Ruby project and run a parser on each file that has been changed. When I do that, I generate 'method events' which represent the event of a method having been added, changed, or deleted. By collating that data, I can see a history of all the methods over the life of the project. Once I have a database of that information (a CSV file, really) I can load the data and perform queries like the one above.
The code snippet gives you a list of all of the methods in your codebase that have increased in length over the last N commits that have touched them.
Presented with that information, people might even act upon it.
That's a really cool idea. I wonder if you also might get an added bonus from the observer effect. Specifically, the fact that everyone on the team knows that the lengthening of methods is tracked might result in people being more hesitant to do it.
Posted by: Erik Dietrich | September 06, 2012 at 08:54 AM
I would hope that that would help. So much of this is social dynamics, isn't it?
Posted by: Michael Feathers | September 06, 2012 at 09:36 AM
Much of this _is_ social dynamics, which is why one should probably think twice before setting this up as something that is "tracked". I appreciate that this can give valuable insights, just as other metrics can; even test code coverage _can_ give valuable insights, but I think we've also all realized that tracking code coverage can lead to some very counterproductive behavior, because of the social dynamics involved.
Posted by: Chr_horsdal | September 07, 2012 at 12:44 AM
Hi Mike, I've been thinking about this since I saw you present it at #aotb. It seems very closely related to the open / closed principle. In our code base we're always thinking about ways to design the code to allow extension rather than modification so I am interested in being able to see a breakdown of how much of the code being added is extension and how much is modification. This would allow us to go and look what's happening when the balance in changing (one way or another).
What I'm struggling with is that whether you see extension or modification does depend heavily on how far back you look. Do you have any observations/comments on how the view changes when you change the value of 'n'?
Posted by: Ed Sykes | September 19, 2012 at 06:33 AM