 |
Java. Quality. Metrics (part 5)
Posted by cos on December 23, 2005 at 05:55 PM | Comments (4)
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
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
I think duplication is worth mentioning. A recent project I was on used copy and paste way too frequently, and they didn't even recognize the problem. They justified it by saying they were 'prototyping' one class from another. Duplicate code means that a bug will need to be fixed multiple times - gross.
Posted by: jessewilson on December 29, 2005 at 09:10 AM
-
If by duplication you mean code reuse then yes I would buy your saying about copy & pasting being an indication for "smelly" code.
Most modern programming languages are aimed to allow for code reuse without retyping; they even encourage us to write more abstract hence reusable code. Thus if one finds himself / herself copy & pasting big pieces of code one should start to think whether he / she is utilising the subclass / superclass hirerachy in Java to its full.
Posted by: alexlamsl on January 02, 2006 at 08:01 AM
-
If you have problems with code duplication, you should look at the PMD project on SourceForge. One of the tools is called CPD, and it does an excellent job of copy-paste detection.
Posted by: javalori on January 02, 2006 at 10:23 AM
-
Thanks for your comments. I had added a notion of code duplication into the article.
Cos
Posted by: cos on January 02, 2006 at 01:39 PM
|
java.net RSS Feeds
