Discovering Software Rot

Since I have seen some announcements about talks targeting the German Corona Warn App, I was interested to see, what kind of information I could extract with Sonargraph.

The project is still pretty young, but maybe, there is already some structural erosion happening? (Spoiler: There is!)

This blog post is about the setup of the analysis-pipeline consisting of Sonargraph-Build and Sonargraph-Enterprise that allowed me to analyse 24 versions (1.4.0 to 2.9.0) of the CWA-Server project and investigate metric trends.

The execution is implemented in Java and published as a new repo “Sonargraph-Build Batch“. If anybody is interested in analyzing past versions of a project with Sonargraph, “Sonargraph-Build Batch” can serve as a starting point.

Read More

Recently Added Usability Improvements

During the last months we released a couple of major features in Sonargraph that allowed easier interaction like the ‘Architectural View’ and improved the interpretation of results like the ‘System Diff’, ‘Quality Gates’ or ‘Issue Ranking’.  We have described the power of these features in individual blog posts.

Some implemented improvements are less obvious, but nevertheless can have a big impact while working with Sonargraph.

This blog post highlights four hidden gems that the casual Sonargraph user might not know about:

  1. Improved issue to resolution matching
  2. Filtering in tables
  3. Visualizing cycle croups in Exploration view
  4. Passing selection between Sonargraph and Eclipse IDE
Read More

Identify the Most Relevant Issues to Fix

Using Sonargraph to analyse a large code base usually reveals a lot of issues. The “System Diff” helps to keep the quality level by highlighting new and worsened issues as described in a previous blog post. But up to now there has been no recommendation about which of the already existing issues should be fixed first.
The new “Ranking” view available in Sonargraph 11.5 does exactly that and this blog post describes how it works.

Read More

Motivation for Code Quality

The main idea behind Sonargraph has always been to provide a tool that eases the creation and maintenance of high-quality software. For any serious project that must live longer than a couple of months, it is actually cheaper to spend a part of your resources to keep your software constantly at a good level of quality than using all your time to create new features. Martin Fowler explains this very well in his article “Is High Quality Worth the Cost?”. The bottom line is, that apart from the very early development stages, high-quality software is actually cheaper to develop, because it allows adding new features at almost constant speed, whereas it becomes more and more time consuming to add new features into a code base with low quality. According to our experience the most successful teams spend about 15% to 20% of their time on code hygiene.

We at hello2morrow believe that a consistent architecture is a fundamental part of software quality. When we use the term “architecture”, we think of it in terms of the IEEE 1471 standard:

“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”

This blog post describes why architectural design as an activity is needed, why conformance checks need to be done automatically by a tool and how Sonargraph supports you as a developer and architect during these activities.

Read More

Efficiently Track the Quality of a Code Base

Sonargraph offers a wide range of checks for different aspects of software quality: Architecture, metric thresholds, cyclic dependencies, duplicate code, etc.
When Sonargraph gets introduced for software projects that have been developed a couple of years, chances are high that hundred’s of issues are reported. But getting flooded with issues and sifting through them at regular intervals is neither efficient nor really helpful. Instead, you want to get a quick overview whether or not the quality is going into the right direction.

And this is where quality gates come into the game: they allow focussing on the information important to you.

This blog post details how this functionality is implemented in Sonargraph.

Read More

Using Sonargraph’s “System Diff” for Continuous Code Quality Improvements

Sonargraph often discovers a huge number of issues for large software projects. This is especially the case for projects that do not use static code analysis tools and that have many contributors. The analysis results can be overwhelming because it is not obvious where to start with quality improvements.

A common best practice to improve code quality is “to keep a lid on it” by preventing further issues to be introduced in new code and gradually improving existing code where it needs to be changed. This is described by Robert Martin as the boyscout rule: “Always leave the campground cleaner than you found it.” [KH]

This blog post explains how Sonargraph’s “System Diff” feature helps to focus on recently introduced issues that need the developer’s attention.

Read More

Implementing Additional Metrics Using the Sonargraph Script API

With the Sonargraph 9.10 release, we added support for two additional OO-metrics “Depth of Inheritance” and “Number of Children” as described by Chidamber and Kemerer. Sonargraph provides a powerful Script API that allows implementing new metrics as Groovy scripts and I needed surprisingly little amount of code for the implementation. This blog post will explain the scripts’ code and the used Sonargraph Script API in detail.

Read More

Automatic Detection of Singletons

Today, we released a new version of Sonargraph with an improved script to find Singletons. “Singleton” is one of the design patterns described by the “Gang of Four” [1]. It represents an object that should only exist once.
There are a couple of pros and cons for a Singleton that I won’t go into detail in this blog post. For anyone interested, I recommend “Item 3: Enforce a singleton property with a private constructor or an enum type” in “Effective Java”, written by Joshua Bloch [2]. Two interesting links that came up during a quick internet research are listed as references [3] [4]. Let’s just summarize that it is important to ensure that Singletons are properly implemented to avoid bad surprises (a.k.a bugs) in your software. And you should keep an eye on the existing Singletons and check that they are not misused as global variables.

This blog post describes, how you can detect Singletons by utilizing the Groovy scripting functionality of Sonargraph.
Read More

Use SonarQube + Sonargraph Plugin to Detect Cyclic Dependencies

Cyclic dependencies have long been seen as a major code smell. We like to point to John Lakos as a reference [Lako1996], and a Google search about this topic will bring up valuable resources if you are unfamiliar with the negative effects. In this blog post, I take it as a given that you are interested in detecting cycles and that you agree that they should be avoided. If you see things differently, that’s fine by me – but then this blog post won’t be really interesting for you.

A number of static analysis tools exist that can detect those cycles in your code base automatically. SonarQube was one of them, until the Dependency Structure Matrix (DSM) and cycle detection was dropped with version 5.2. The DZone article by Patroklos Papapetrou (“Working with Dependencies to Eliminate Unwanted Cycles”) and the SonarQube documentation (“Cycles – Dependency Structure Matrix”) illustrate the previous functionality.

I noted that some people are missing those features badly and complain about their removal. The comments of the issue “Drop the Design related services and metrics” and the tweet of Oliver Gierke are two examples.

But thanks to the SonarQube ecosystem of plugins, there is a solution: Use the free Sonargraph Explorer and the Sonargraph Integration Plugin to get the checks for cycles back in SonarQube!
I will demonstrate that the setup and integration of Sonargraph into the build is fast and easy.

Read More