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 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 • Reek • Flog • Roodi • Saikuro • Flay • Rails ‘stats’ • 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: Explain that Saikuro measures cyclomatic complexity Hey, where’s the dynamic one? 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 http://jakescruggs.blogspot.com Blog Home Page http://metric-fu.rubyforge.org Group http://groups.google.com/group/metric_fu GitHub http://github.com/jscruggs/metric_fu