using metric_fu to make your rails code better
DESCRIPTION
You’ve got yourself a Rails project and a bunch of developers. Some of those devs are awesome and others are… not so awesome. How can you make sure that your beautiful code doesn’t degrade over time as more people join the project and deadlines loom? Or maybe you’re on a project that has lots of “bad parts of town” and you want to make it better – how will you know if you’re really making a difference? And where to start? Well, the growing field of code metrics is here to help. There are tools to measure test coverage, code complexity, churn (code that needs to change whenever anything changes), bad practices, duplication, and code smells. And all of these various open source projects have been mashed together in metric_fu – a Ruby gem that makes measuring the quality of your code easy (or at least easier).Watch a video at http://www.bestechvideos.com/2009/05/13/using-metric_fu-to-make-your-rails-code-better-jake-scruggsTRANSCRIPT
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