Using metric_fu to Make Your Rails Code Better

Using MetricFu to Make Your Rails Code Better

Jake ScruggsSenior Consultant @ Obtiva

Boring who am I stuff

• High School Physics teacher

• Apprenticed at Object Mentor

• 6 projects at ThoughtWorks

• Now a consultant at Obtiva

The hell is a metric_fu?

• It’s a mash-up of various code analysis tools

• I got tired of re-writing the same rake tasks on every project

• It’s since become much more

How do I use it?

Run the following if you haven't already:

gem sources -a http://gems.github.com

Install the gem(s):

sudo gem install jscruggs-metric_fu

(You may crash the wifi if you do this now)

Then what?

• require ‘metric_fu’ in your Rakefile

• Or you could vendor it because you’re a good person

• And then: rake metrics:all

Bang zoom, you’ve got some metrics

Why do this?• Code rots one day at a time

• George Carlin’s Law: “Everyone slower than me is stupid, and everyone faster is crazy”

• Prioritize your efforts

MetricFu uses a bunch of open source projects

to give all this to you

• Rcov

• Flog

• Saikuro

• Rails ‘stats’

• Reek

• Roodi

• Flay

• Churn

Code Coverage:

So easy you’re probably already doing it

What’s a good coverage number?

• With Ruby, 100% is very possible

• 30% is bad, but 100% may not be good

• But are my tests any good?

• A good goal is as many tests as there are paths

Sadly

• Code coverage means something when it’s low, but may mean nothing when it’s high

• Still, it has its uses

• C1 or C2 coverage would be cool

C0 is did you hit the line -- Rcov measures thisC1 deals with partially executed lines: if foo() and bar() #foo() could return false and bar() would not executeC2 deals with all the possible paths through a method:see rcov.html

Complexity Measurement

Saikuro Flog

Managing complexity is just as important as TDD

• If you had to choose:

• Spaghetti code with spaghetti tests

• Well factored code with no tests

Yes, properly done TDD should produce good design. However, people seem to forget about the refactor

part of Red, Green, Refactor

Flog score example:

the numbers don’t add up

General guidelines for flog scores per method

• 0-10 Awesome

• 11-20 Good enough

• 21-40 Might need refactoring

• 41-60 Possible to justify

• 61-100 Danger

• 100-200 Whoop, whoop, whoop

• 200 + Someone please think of the children

Flog is Opinionated

• Documentation is lacking

• But its relative scores are good

• More importantly, Flog knows where the badness lives in Ruby

Saikuro Example:

Hey, where’s the dynamic one?Explain that Saikuro measures cyclomatic complexity

Explain Cyclomatic Complexity

Saikuro uses a simplifed CC calulation -- just closed loops and not paths

How does Flog do?

So now what?

• Create a ‘hit list’ of your most complex methods

• Examine the worst offenders

• Refactor, refactor, refactor

Damerau Levenshtein Distance Example

Refactoring complex methods yields many

benefits

• Smaller, easier to understand methods

• Finding bugs

• You can see past the craziness and into the code

Why inject sucks

• Keep in mind that new developers will be joining your team

• Remember Carlin’s Law: “Everyone slower than me is stupid, and everyone faster is crazy”

Consider these methods:

Explain Yourself

• If you really believe the complexity is a net gain then keep it, but explain

• framework code

• complex problem space

• Test it well -- more complexity means more tests (one per path is a good goal)

• Ex: ‘Data’ Serialization

Rails Stats (rake stats)

Reek(code smells - may not be bad)

Roodi(more selective about reporting)

Flay

Source Control Churn

Look for Outliers with Churn

• It may be a ‘god’ object

• It may also be a view that changes a lot

• Try to let metric_fu help you challenge your assumptions

All this gets put into a yaml file

So you can consume or mash it up as you like

Creating a new metric_fu metric

• Ex. I want to analyze git logs to find out people’s check in habits

• Inherit from Generator.

• Implement: Emit, analyze, and to_h methods

• Write a template to display the hash

(Show an example)

Continuous Code MetricsI highly recommend using CruiseControl.rb or

Integrity to set up a metrics build.

Metrics: the downside

• Numbers do lie

• Any analysis tool has an opinion

• ‘Bad’ Numbers may be good

• Managers and code metrics:

• If they’re not in the code they can’t make judgment calls

• Gaming the system

What Code Metrics can do for you

• Help you prioritize

• Shine light on unknown problems

• bugs

• hidden complexity

• Provide another perspective

Metrics are not a ‘Fire and Forget’ operation

If your code is not getting better every day then it’s

getting worse

ThanksMe Jake Scruggs

Blog http://jakescruggs.blogspot.com

Home Page http://metric-fu.rubyforge.org

Group http://groups.google.com/group/metric_fu

GitHub http://github.com/jscruggs/metric_fu