To Sonar or Not to Sonar?
Join the DZone community and get the full member experience.Join For Free
To Sonar or not to Sonar?
This is the first question that a project/product manager, team leader, software department director, customer, developer, ui designer, architect, tester or whatever role/title exists in a development team should answer. This is not a simple question about using an additional quality tool to help you with software development by providing some statistics. I suppose we all have plenty of them installed. This is not a simple question to see how much you care about the total lines of code and their test coverage or to find which classes have the most violations. There is no competition and no prize about that! It is the only question that you ought to answer in order to show how much you care, how much you REALLY care about the overall quality of your software. If you already use Sonar, then you should probably already know the answer and feel free to read our experience. On the other hand if you have never used Sonar 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.
I am an employee of a relatively small software development company, located in Thessaloniki, Northern Greece. There are about 25 developers currently working in small teams. The last 1 ½ years I am in charge of a team composed by 8 members. We are responsible for the maintenance of 5-6 systems (products) and in the meanwhile we have completed a project for one of our customers. Currently we are working on two new products. Since last May (2010) we are using Sonar and here is my little fairy tale about it.
Can I describe our development life before Sonar with a simple word? Of course I can!! Darkness. We had no idea of the situation in our code. We run no unit tests. We did not know whether the design and architecture of our systems allowed significant additions of new features or important changes, which made us very apprehensive about any refactoring attempt. Violations; Security flaws; what the heck are these? Duplicate Code? God bless copy – paste. Analyzability, Testability, Stability, Changeability were terms we believed that 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 cannot remember how I reached Sonar website, but right now I am quite sure that, those 10 minutes needed to read some of Sonar features, changed my development life. Without any second thought I downloaded it and in a couple of minutes it was installed in my personal computer. Full of excitement I configured it to be integrated with Maven and Jenkins (Hudson at that time) and after a couple of minutes I was starring at my screen in front of my first ever Sonar analysis. I admit that my initial feeling was an extreme disappointment regarding the quality of our existent product but as soon as I realized the possibilities of this unknown to me software tool, I was absolutely stimulated about our new life. Immediately I showed it to my team, shortly explaining them, the different metrics and what do they mean about our project, about the QUALITY of our software. A new era has begun.
Today, almost one year later, Sonar tracks all our projects through nightly builds – analysis. Every morning the whole team checks the project dashboard, and the differential views, especially from last analysis, and from last stable version. We have configured thresholds for the metrics we count the most, so whenever a build is out of the accepted limits, it is broken. We handle these builds just like all broken builds. It is our first priority to fix a sonar-broken build and to restore the required quality. Before we begin a refactoring task we always study our Sonar analysis related metrics to find out signs of poor design or architecture. We continuously strive to be focused on every aspect of software quality from the first day of the project and without any doubt; Sonar is the best ally we could ever hard. My favorite views are Treemap and motion Chart? I love to see my bubbles changing colors and moving towards perfection. I love to see my tree getting green from red. With a single view I can figure out which components need our further attention. It’s easy! 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 have to add some new functionality or modify existing features. In other words, this is our Sonar life!
The new version, 2.8, is already out there and I cannot wait to try some of its new features like quality profile comparison and manual reviews. I would be also very happy if we could purchase the SQALE plugin. Come on Sonar guys I am sure you can do a better pricing for this kind of plugins. I can’t imagine my development life without Sonar. Ι sometimes wonder how we and our code could “breathe” some months ago. Sonar gave us the missing oxygen.
I have answered my question to myself. I have chosen light instead of darkness. it’s your turn now! TO
SONAR OR NOT TO SONAR?
Original Post : http://onlysoftware.wordpress.com/2011/05/19/to-sonar-or-not-to-sonar/
Opinions expressed by DZone contributors are their own.