Sometimes a class does too much. It's used everywhere, does everything, knows all about the nasty internals of all the other classes, and every time you change anything in the application it has to change. Or maybe you have a class that everyone loves to refactor because it's so bad. One developer changes it to be better, then another changes it to be a different kind of better, and this keeps happening without it ever getting any easier to use. There's a lot of bad reasons why a class might change all the time so I added a churn report capability to metric_fu version 0.6.0.
Now you can use metric_fu to create a report like this:
By issuing this command:
rake metrics:churn
And use the results to find classes that might have problems. It uses 'svn log' to create this report so currently you need to be using subversion. (If anyone out there want to contribute some code to get it working with git, lemme know.) The default is to start counting changes from the start of the repository's creation. That may be too much for your project so you can change the start by adding these lines to your Rakefile:
namespace :metrics do CHURN_OPTIONS = { :start_date => lambda{3.months.ago} } end
The Proc is there because '3.months.ago' only works after the Rails Environment is loaded (and Rails extends Fixnum) which I didn't want to do every time you run a rake task.
You can also change the minimum churn count (files with changes less than this number won't be included in the report) like so:
namespace :metrics do CHURN_OPTIONS = { :minimum_churn_count => 3 } end
Also in this release I added the 'metrics:all_with_migrate' task because of some feedback I got that running 'metrics:all' in a cc.rb build fails if there have been migrations. So the new task migrates the test db before running all the metrics tasks.
Check out the metric_fu project home page for more information and installation instructions. Or you can jump right in by doing this in the root of your project:
Previous Topic
