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

• 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

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


(more selective about reporting)



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

Me Blog Home Page Group GitHub Jake Scruggs

Sign up to vote on this title
UsefulNot useful