Your Rails Code Better Jake Scruggs Senior Consultant @ Obtiva - - PowerPoint PPT Presentation

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

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