Java. Quality. Metrics (part 5)

Java. Quality. Metrics (part 5)

The link above hasn’t been redirected property lately, so here’s the copy of Google’s cache for that article:
 

Java. Quality. Metrics (part 5)

Posted by cos on December 23, 2005 at 5:55 PM PST
Hi there again.

Getting back to my favorite topic about quality of life… I meant that pseudo-life, we all are trying to make. And if there’s Something, what had once created all of us and everything else around – it did a way better job 😦 But, I think, we have deserved a credit too: we don’t have all the time in the eternity to finish our job by trial and errors approach. An average man leaves about 70 years; say 30 years of which she spent in diapers, at school or on medications in front of TV, purchased on retirement money. Which left us with roughly a 40 years term, split between personal and professional life (change the order if you want to 🙂

All my professional life is literally coupled with computers (I have six of them at home, including an old Sun’s SparcClassic LX and not including my Palm Pilot). And as more and more software is coming into our lives, I’m wondering if I can rely on it and where are the limits of this trust. Also, as a participant of Java software development cycle I want to do better job myself and help my colleagues to do same: namely spend less time to develop more robust software.

This brought me to the point of quality indicators definition. What will be the right criteria to determine if a piece of software will break or not in customers hands. And again, where is the right target to aim our testing efforts and wether or not they are efficient?

After some consideration we humbly came up with the following list:

  • code complexity? Yes, this is the beast. If you have methods as long as 3+ screens it’s bad. If you class hierarchy contains 5+ levels – it’s not good either. Does it smell right, if you have 300+ lines of code/class?
  • a frequent code changes? Or even changes per feature or bug? Yeah, perhaps. If you do have about 5 commits per bugfix it doesn’t sound right at all. However, I can imagine some other considerations.
  • poor code coverage? Yes, one of the kind. But even coverage numbers can’t save you from troubles. It isn’t a panacea.
  • design and coding styles? Well, may be. Stylish code is easier to read, understand, but not necessarily to maintain. And if coding styles are easy to check, design style’s flaws might not be that easy to find and eliminate. Patterns are helping here in particular, but you have to know where is the fine line between good design solution and simple yet sufficient implementation
  • code duplication? Not in a sense of reuse, but in a way of overuse of copy-n-paste “technique”. Yes, ugly enough. As one of my readers had appointed – if one had introduced a bug in a code, which was copied a few time later then one will end up with a multiple copies of the same bug hidden all over the place 😦 There’s a number of automated ways to find and fix these rotten spots. One of them named PMD was mentioned by another reader of the article and can be found here
  • Thanks to all of you sending comments or expressing interest otherwise. If you can imagine or know more of these from your practice – please send them in and I’ll gladly add here any reasonable ones.

Well, assuming that now you got a data for all from above and then some. What and how you’ll deduce from here?

Let’s talk about this after I get back from that nice winter break. How about open sourcing some ideas? Ok, I’ll share (swear!) the principles of the technology we’re working on for last few months.

Best of everything to all of you and Happy New Year to everybody. Also, Merry Christmas to those who believe in Santa Clause or whatever you can call that dude, who knew something about quality in a long term!

Cheers!
  Cos