Software Development Quality Control

with

SONAR

Cornelius Mellino, PMP.

From theory ... into practice

• Learning experience : IS Management at Binus MMSI. (2008-2010)

• Working experience :

• IT Manager at Prasetiya Mulia. (2009)

• Senior Java Developer at Knowment AIE. (2010)

• Project Manager at Telkomsigma (2011-now)

Experience without theory is blind, but theory without experience is mere intellectual play. – Immanuel Kant

Scenario 1:

• Your team doesn’t collect code metrics from projects. Therefore, your code base could be getting worse and worse without anyone ever noticing. You might start noticing when the technical debt (we will elaborate on this concept later) has reached a

certain level where it’s tooexpensive

to address them, given the time and budget constraints.

http://blogs.sourceallies.com - Akrem Saed

The Answer

• Collecting code metrics continuously can give your team the advantage of keeping the technical debt of your code base under control. For example, you can make it a rule that you don’t allow your code base to extend beyond a certain threshold in terms of some metric values. Whenever that threshold is reached you are notified immediately through your continuous build.

• Implements LEAD MEASURES

Scenario 2:

• Time and time again I’ve witnessed teams that start refactoring because they are convinced

the code base was bad in terms of performance, brittleness, instability, difficulty to maintain and/or to extend. While our intentions are good, we don’t know what part of the code base is responsible for the issue we encounter. Hence, there is a good chance changes will be applied to the wrong code. Or we end up refactoring the right code in the wrong way. Or we only fix part of the problem.

http://blogs.sourceallies.com - Akrem Saed

The Answer

• This is where metrics and tools like Sonar can help.

• Sonar points out the parts of the code that

are causing problems.

• Once these issues are identified they can be prioritized and added to the backlog.

• Sonar helps teams identify and address issues with confidence.

Scenario 3:

• Another team is the best in the world and has remarkable instincts in identifying and correcting issues, but they fail to track the quantity of issues fixed in their triumphant voyage.

• Let’s face it, managers and team leaders would definitely appreciate having a clear idea of how many improvements were made with their resources and budget.

• They also want to know which issues still need to be fixed in the future.

http://blogs.sourceallies.com - Akrem Saed

The Answer

• Now, if you preserve a snapshot of metric values before the voyage, you could report something like this “… before our code base was 75% compliant with the company’s best practices and now it’s at 95%”.

• Sonar helps you track your improvement progress.

If you can’t measure it, you can’t improve it. - Peter Drucker

Why Sonar?

• Free

• Quantitative measurements of code quality

• A set of measurement metrics

• Discourage bad practices

Quantitative measurementsof code quality

A set of measurement metrics

Discourage bad practices

Sonar give guidances

Broken Window Theory

• Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

Broken Window Theory

• We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

• You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.

• Continuously collecting and reviewing

software metrics can help identify and fix “broken windows” before they affect other windows.

• The longer a bad design and bad code are left unfixed, the more vulnerable your code is to receiving additional hacks. Leads to bigger Nonconformance Cost.

http://blogs.sourceallies.com - Akrem Saed

“Quality is not an act, it is a habit.”

―Aristotle

Sonar is Not Alone

• Sonar uses various static code analysis tools such as Checkstyle, PMD, FindBugs, Clover to extract software metrics, which then can be used to improve software quality.

The Metrics

Technical Debt

http://c2.com/doc/oopsla92.htmlhttp://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin

The Formula

• Debt(in man days) =

cost_to_fix_duplications

+ cost_to_fix_violations

+ cost_to_comment_public_API

+ cost_to_fix_uncovered_complexity

+ cost_to_bring_complexity_below_threshold

http://c2.com/doc/oopsla92.htmlhttp://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin

The Formula

• Duplications = cost_to_fix_one_block *duplicated_blocks

• Violations = cost_to fix_one_violation *mandatory_violations

• Comments = cost_to_comment_one_API *public_undocumented_api

• Coverage = cost_to_cover_one_of_complexity *uncovered_complexity_by_tests (80% of coverage is the objective)

• Complexity = cost_to_split_a_method *(function_complexity_distribution >= 8) + cost_to_split_a_class * (class_complexity_distribution >= 60)

http://c2.com/doc/oopsla92.htmlhttp://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin

Duplication

Complexity

Sonar Metric Definitions

• http://docs.codehaus.org/display/SONAR/Metric+definitions

o Complexity

o Design

o Documentation

o Duplications

o Reviews

o Rules

o Size

o Tests

“Quality is everyone's responsibility.”

―W. Edwards Deming