On Tue, Jan 22, 2013 at 12:05:23PM +0100, Imre Farkas wrote:
Hi,
Yesterday I came across a new service called Code Climate which
provides code metrics based on static analysis of the code. It is
only for Ruby and it's free for opensource projects. I added
Conductor and it gave the result back in a minute. You can check them
at:
https://codeclimate.com/github/aeolusproject/conductor
This is awesome. Thanks for setting this up.
I think it's a pretty awesome service and I would like to take
one
step further. Ideally, we could use this site with the intent to
improve our code quality. Currently, a huge part of our business
logic is concentrated in a few classes. It's already causing
headaches for us and it will just get worse. Martin also wrote about
the need to refactor certain parts of our codebase [1], with which I
completely agree.
To handle this issue we could allocate a small portion of every
sprint from now on to refactor the worst part of Conductor. Using
Code Climate, we can identify hot spots easily (not that it would be
hard on our own) and we will receive instant feedback on our effort.
I went to a really interesting talk by Chad Fowler some time ago, and he
talked about some of these concepts. (Not the specific site, though.)
One of the things I was really interested in was his talk was the
concept of churn vs. complexity. Every project seems to have that really
complicated class that "just works" and hasn't been touched in ages --
that's not great, but it's not causing any problems, either. What's
especially dangerous is the code that's complex _and_ changed all the
time -- high complexity and high churn.
It turns out that we get exactly that graph on the lower right of
https://codeclimate.com/github/aeolusproject/conductor/trends -- the
stuff on the upper-right is arguably the most pressing, since it's both
complex _and_ frequently-modified. (I'm assuming that it's getting this
data from git history, not from the time the project has been hosted
there -- otherwise there's not nearly enough data for the 'churn' metric
to be meaningful yet.)
I don't love that it gives us a letter grade, A-F, for each bit of code.
It makes it easy to understand, but I think it also makes it too easy to
fall into a trap of taking its suggestions as gospel. Poking around, I
seem to agree with everything it's complaining about. But I think the
decision of what to refactor should always be based on a human's review
of code (assisted by tools like this), not just based on the letter
grade it gives. (No one has argued otherwise, and I agree with the
approach of refactoring the complex code. I just think it's important to
remember that we're ultimately in charge.)
-- Matt