• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

how does your CM tool help you?

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, folks, me again: your friendly local columnist for Software Test & Performance magazine. I'm looking for input for my next "best practices" (aka "Things I learned the hard way") column, and I hope you can help me.

What are your favorite metrics for measuring code quality from your CM system? That is, what do you look for in the reports your SCM system generates, and how do you use that information to do a better job?

Are the reports included with your package enough? Or do you find that you create custom views of the data to get a unique twist on what you're doing? If so, what are you most apt to look for... and why?

I need to hand in the article by the middle of the month, so it'd be great if you could reply to me (privately if necessary) by January 12th... ideally with some way to identify you in the article (name, company, title, geography).

Esther Schindler
contributing editor, Software Test & Performance magazine (stpmag.com)
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We currently mostly use three measures:

- the most obvious one is unit tests. They are expected to increase in number more or less linearly - if they don't, it tells us something interesting. Of course a failing test is something that needs to be fixed immediately (the whole system - more than 1 million lines of code - is build and tested once an hour).

- frequency of build failure. We are using Cruise Control to start, monitor and report on automatic builds. It has a nice chart showing the chronological succession of build successes and failures. The patterns in that chart mostly tell us interesting things about our process.

- code size. Working on a legacy system, we typically expect code size to decrease while refactoring the system to incorporate new features.

Ilja Preu´┐Ż, disy Informationssysteme GmbH, software developer, Karlsruhe Germany
 
author & internet detective
Posts: 40198
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By CM system, do you mean our change management system? That would be CVS, but it doesn't produce reports on code quality that I know of. Once in a while, we use CVS to see how often a class/project has been updated. We also have an Ant build, but not up to Cruise Control yet.

With other tools:
We look for code coverage over time. That code coverage increases on existing code and starts out hight on new code. We look for any critical static analysis (coding standards, common bugs) from JTest - a commercial tool. And of course, we look to make sure the code compiles.

We use this information to do a better job by seeing where to focus on. For example, if certain types of code don't get tested, we see how to better test it. Over time, we've found that the information we have isn't as useful and add new things to monitor/report on. I think this is because we have a tendency to focus on what is being measured. Once it is measured, we master that, get used to it and go on to the next thing.

Jeanne Boyarsky, Java Developer for a bank in New York City
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
Once it is measured, we master that, get used to it and go on to the next thing.



Very well said!
 
Esther Schindler
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
By CM system, do you mean our change management system? That would be CVS, but it doesn't produce reports on code quality that I know of. Once in a while, we use CVS to see how often a class/project has been updated. We also have an Ant build, but not up to Cruise Control yet.




Yup, I meant the change management system. And it doesn't have to be a report, per se. One guy I corresponded with says he looks at how long a developer has code checked out; several units that are "too short" or "too long" merit attention, because something odd is going on.

In what way does it help to look at how often a class/project has been updated?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our team strives to practice continuous integration - that is, checking in changes every couple of minutes to hours. The simple reason is that longer checkouts increase the chance of conflicts and thereby hamper merciless refactoring.

We don't really monitor this - I think we actually couldn't, as we don't use a pessimistic locking system.

eRose is a tool that might interest you: it tries to suggest code you should take a look at based on what you have touched and statistics from CVS what typically gets touched together. I haven't really tried it yet, though, as for the size of projects I'm typically working it needed too many resources. See http://www.st.cs.uni-sb.de/softevo/erose/
 
Jeanne Boyarsky
author & internet detective
Posts: 40198
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We do continuous integration as well.

>In what way does it help to look at how often a class/project has been updated?
When we have problems we sometimes do this. Eclipse provides a nice interface for looking at the released versions of a file. And we look at the CVS logs for the last time someone released/pulled in a file when there are problems.

But on a regular basis, we don't look at the CVS reports. It will be interesting to read this article when it comes out to see what others are doing.
 
His brain is the size of a cherry pit! About the size of this ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic