Using MetricFu to Make Your Rails Code Better

Jake Scruggs Senior 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: • Prioritize your efforts
“Everyone slower than me is stupid, and everyone faster is crazy”

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 this C1 deals with partially executed lines: if foo() and bar() #foo() could return false and bar() would not execute C2 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 • 11-20 • 21-40 • 41-60 • 61-100 • 100-200 • 200 +
Awesome Good enough Might need refactoring Possible to justify Danger Whoop, whoop, whoop 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:

Explain that Saikuro measures cyclomatic complexity Explain Cyclomatic Complexity Saikuro uses a simplifed CC calulation -- just closed loops and not paths

Hey, where’s the dynamic one?

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

• Test it well -- more complexity means • Ex: ‘Data’ Serialization

• framework code • complex problem space

more tests (one per path is a good goal)

Rails Stats (rake stats)

(code smells - may not be bad)

Reek

(more selective about reporting)

Roodi

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 Metrics
I 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

Thanks
Me Blog Home Page Group GitHub Jake Scruggs http://jakescruggs.blogspot.com http://metric-fu.rubyforge.org http://groups.google.com/group/metric_fu http://github.com/jscruggs/metric_fu

Sign up to vote on this title
UsefulNot useful