About Patroklos Papapetrou

Patroklos is an experienced JavaEE Software Engineer and an Agile enthusiast seeking excellence in software quality. He is also co-Author of the Sonar in Action book, and contributor of several Sonar plugins.

To SonarQube or not to SonarQube?

This is the first question that a team leader, s/w director, customer, developer, architect, tester or whatever role exists in a development team should ask. It’s not yet another question about using another “quality tool”. You already have plenty of them installed. This is not a simple question to see how much you care about test coverage or to find which classes have the most issues. There is no competition and no prize about that! It’s the only question that you needto answer in order to show how much you care, how much you REALLY care about the overall quality of your code. If you have never used SonarQube or even heard about it, then this is your chance to find out how this little (but great) piece of software have changed our lives (as developers) and enhance our products.

Darkness. This is how I describe our development life before SonarQube. We had no insights of our code. We ran no unit tests. We did not know whether the current design allowed us to quickly add new features or make important changes, which made us apprehensive about any refactoring attempt. Coding rules; Issues; what the heck are these? Duplicate Code? God bless copy – paste. Testability, Stability, Changeability were terms we needed to look-up in a Chinese dictionary to find out their meaning. Bugs were discovered late in the development lifecycle causing some red-alert situations and releases seemed to be some kind of middle-age dragons that our support and test department had to fight before they come out to our customers. And then some kind of a miracle happened. I can’t remember how I reached SonarQube, but right now I am quite sure that, those 10 minutes I needed to read SonarQube’s features, changed our mindset.

Without any second thought I downloaded and installed it. Full of excitement I analyzed my favorite project and after a couple of minutes I was starring at my screen in front of my first ever SonarQube dashboard.My first feeling was an extreme disappointment:”Our code sucks!”. Soon I realized the possibilities of this unknown to me tool and I was stimulated about the potentials. Immediately I showed it to my team, shortly explaining them, the different metrics and their meaning about code quality. A new era has begun. Today, SonarQube tracks all our projects. Every morning team members check the project dashboard, especially the differential views from last analysis. We have configured thresholds for the most important metrics, so whenever new code reach a threshold, build is broken. We handle these builds just like all broken builds: Fix them ASP and restore the required quality. Before we begin a refactoring task we always consult SonarQube for signs of poor design. We continuously strive to focus on code quality from the first day of the project and SonarQube is the best ally we could ever hard. I love to see my bubbles(Motion Chart) changing colors and moving towards perfection. I love to see my projects treeview getting green from red. With a single view I can figure out which components need our further attention. Just pick up the red big-ones and start cleaning up your code!

Our new product releases are much more stable. From dragons are transformed to butterflies. Trust and confidence in our team has significantly grown. We feel no fear when we add new features or modify existing ones. In other words, this is our SonarQube life! Sometimes, I wonder how our code could “breathe” some years ago. SonarQube gave us the missing oxygen. I have answered the question to myself. I have chosen light instead of darkness. it’s your turn now!
 

Reference: To SonarQube or not to SonarQube? from our JCG partner Patroklos Papapetrou at the Only Software matters blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


8 + = seventeen



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books