Difference between revisions of "BuildMetrics"

From CitconWiki
Jump to navigationJump to search
(New page: Interesting metrics: * Quality? * Near to release? Adding code coverage to every build * % of code * % of branches * watch the trend * trend should grow * Cobertura shows this When trans...)
 
Line 18: Line 18:
 
* findbugs
 
* findbugs
 
* checkstyle
 
* checkstyle
 +
* jdepend
 +
* complexity metrics (NCSS, Callistic)
 +
* links between metrics highlighted
 +
* defects added
 +
* defects corrected
 +
* densisty of defects for project
  
 
Metrics from CI system:
 
Metrics from CI system:
Line 25: Line 31:
 
* pairing matrix
 
* pairing matrix
 
* time for completion for user story
 
* time for completion for user story
 +
 +
Bumble
 +
* identifies which unit test breaks the build the most
 +
 +
What is the real use of the metrics?
 +
 +
 +
Use of metrics will affect behaviour of developers.
 +
 +
Experience of setting up Sonar. Often fails, developers start to ignore
 +
 +
Much easier if you start  with new code, and don't let new  defects in. Keep clean. Harder to apply to legacy code, because the number of warnings if often overwhelming.
 +
 +
Ivan: story of project that used static analysis tools from the start, but the code was a complete mess. This was probably as a direct result of the tools used for measurement
 +
 +
Interesting to correllate bugs to programmer or pair.
 +
 +
Book "Measuring and Managing Performance in Organisations": if you manage people by a metric, they will responding by gaming the system. That doesn't necessarily mean that you shouldn't use the metrics
 +
 +
Need to carefully choose which metrics to measure, and interpret intelligent conclusions from metrics. Can necessarily do this automatically.
 +
 +
Learning how to use the information presented. Collate data. What will the team do with the information? Will external groups monitor the metrics?
 +
 +
BI (Business Intelligence) - managers see similarities with code metrics. Can be helpful to distill code metrics to simplifed metrics based on threasholds. eg. very maintainable

Revision as of 07:06, 19 September 2009

Interesting metrics:

  • Quality?
  • Near to release?

Adding code coverage to every build

  • % of code
  • % of branches
  • watch the trend
  • trend should grow
  • Cobertura shows this

When transitioning to TDD, watch coverage

List of interesting metrics (dynamic or static properites of the product)

  • line coverage
  • branch coverage
  • pmd
  • findbugs
  • checkstyle
  • jdepend
  • complexity metrics (NCSS, Callistic)
* links between metrics highlighted
* defects added
* defects corrected
* densisty of defects for project

Metrics from CI system:

  • time for build
  • time for test
  • commit frequency
  • pairing matrix
  • time for completion for user story

Bumble

  • identifies which unit test breaks the build the most

What is the real use of the metrics?


Use of metrics will affect behaviour of developers.

Experience of setting up Sonar. Often fails, developers start to ignore

Much easier if you start with new code, and don't let new defects in. Keep clean. Harder to apply to legacy code, because the number of warnings if often overwhelming.

Ivan: story of project that used static analysis tools from the start, but the code was a complete mess. This was probably as a direct result of the tools used for measurement

Interesting to correllate bugs to programmer or pair.

Book "Measuring and Managing Performance in Organisations": if you manage people by a metric, they will responding by gaming the system. That doesn't necessarily mean that you shouldn't use the metrics

Need to carefully choose which metrics to measure, and interpret intelligent conclusions from metrics. Can necessarily do this automatically.

Learning how to use the information presented. Collate data. What will the team do with the information? Will external groups monitor the metrics?

BI (Business Intelligence) - managers see similarities with code metrics. Can be helpful to distill code metrics to simplifed metrics based on threasholds. eg. very maintainable