Code Quality: Metrics That Matter

By:

As programmers, we spend a lot of time and bits debating and preaching about the merits of good code and the evils of bad code and the differences between the two. And as Rubyists, we sometimes get a little… What? Self-righteous? Precious about our code? Strong tendency to bikeshed?

OK, we’ve all probably been guilty of that at times. Most Ruby and Rails hackers I’ve worked with and known over the years show a lot of care and craft when it comes to their code, but we do it all in the service of building something that lasts. This is why we go on about skinny controllers and presenters versus helpers. It’s why we write tests. And it’s a big part of the motivtion that has led to the creation of so many tools for evaluating source code quality. This article is going to talk about a few of them that I’ve found useful at various times.

But before we launch into that, there’s an important question that needs answering:

What Are You Gonna Do About It?

No, seriously, that’s a real question.

If all you’re interested in is how to install the gems and run the reports, a bulleted list of links to the READMEs will do just fine. Before you invest any more time, I want you to think about what you’re expecting to learn from them and decide right now what you’ll do when you have that information. This is the piece that’s missing in a lot of the articles and tutorials I’ve seen about code quality tools, and that’s what I’m hoping you’ll be thinking about as you read on.

Code Coverage Coverage matters, but often not in the way people think. A lot of people think that well-covered means well-tested and that well-tested means correct. But just spend a moment thinking about those two statements and you’ll see that there are two big logical leaps in that thinking.

A lot of teams chase after 100% coverage for its own sake or as a seal of approval that they can show to a customer or manager, but there are legitimate reasons to work for high levels of test coverage on your projects. First and foremost is the fact that gaps in coverage are indicative of gaps in your development process. Looking for sections of code where coverage is missing can get you asking the right sorts of questions about why it happened.

Was there something about that code that made it too hard to test?
Is that section a candidate for refactoring?
Does the person who wrote the code need some coaching or guidance to help them improve their testing technique?

Another reason that coverage is important, especially when it comes to Ruby applications, is because it gives certainty that code is executed under test. Why is that important? Because eventually, you’re going to need to update some part of the infrastructure that your application rests on - whether that’s the Ruby interpreter (13 releases in the past year), Rails (12 releases), or some other gem you rely on. When that day comes, having a test suite that covers most or all of your application will mean you don’t have to worry that something is going to blow up in production because of a deprecated method or API.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/