Preface

“Would you like to help me write a book about Sonar?” My reaction was immediate: “Yes!”

I knew Patroklos Papapetrou from the Sonar mailing list, and I was aware that he was pitching Sonar in Action (now SonarQube in Action, to match the technology’s new name) to Manning. What I didn’t know was that he wanted a coauthor. Because I was a native English speaker and active (and helpful) on the list, he thought of me. I had only been a member of the list for about six months, but I’d been aware of Sonar since late 2008 when my boss came across a mention of Sonar and asked me to evaluate it.

I was coding in Java at the time, but I had started my programming career with Perl and C. Lint was your friend, and bugs were found the hard way—by the users. So I found Sonar intriguing. It promised to scan each line of code and point out all kinds of things that were wrong or could go wrong. But to use it, you had to be building with Maven. Unfortunately, we were in an Ant-build shop. Sonar was off the table.

Fast-forward to early 2010. Sonar was approximately three years old, but already it was gaining broad acceptance among community and enterprise users and being downloaded more than 2,000 times a month. Patroklos had found the Sonar website while researching software quality tools, and it was a classic boy-meets-software story. (Cue the sappy music.) It didn’t take long before he was in love and Sonar was one of his favorite tools.

Meanwhile, I had begun moving our Ant builds to Jenkins (it was still called Hudson then), and I stumbled across the Sonar plugin for Hudson. It works differently now, but at the time, it performed a shallow “Maven-ization” of a non-Maven project and ran an analysis. Hmmm. Maybe Sonar was back on the table.

I installed Sonar and the plugin on my localhost and ran an analysis. When I poked around in the results, I didn’t understand everything I was seeing, but I knew I liked the way it presented issues in the context of the offending code. And because Sonar had a web-based front end, instead of having to send quality reports to people, I could send the people to the reports! When I showed my colleagues, they agreed that what we were seeing was good stuff, so we teamed up on our management.

We pretty quickly got first-level management’s buy-in to pilot Sonar, and we started talking about it to anyone who would listen. Pretty soon other teams were approaching me to set them up “with that Sonar thing.” We were seeing a viral adoption. After only a couple of months, management at the next level up said that everyone needed to be on Sonar by the end of the year.

By this time it was early 2011, and Patroklos was an active member of the Sonar community. He had spent 2010 telling everyone he knew about Sonar via his articles and blog posts. He also implemented his first Sonar plugin that year. By August of 2011, he was such a prominent figure in the small Sonar community that another publisher approached him to write a book about it. He was flattered, but didn’t have the time to do it justice, so he turned it down.

But although Patroklos didn’t write that book, he didn’t forget the idea. When his schedule cleared at the end of the year, he approached Manning about writing Sonar in Action. A few short months after that, we were on our way.

Our goal in writing this book has been to condense the SonarQube lessons we learned in the last few years, combine them with whatever wisdom we can lay claim to from our combined 30 years of programming, and put a bow on all of it for you. The first time I ran a Sonar analysis, I didn’t understand some of the things I was seeing, but we don’t want that to happen to you. We’ll tell you not only what SonarQube’s metrics mean, but also why you should care and (unless it’s really, really obvious) what steps to take in your code to get started fixing what’s wrong. We’ll help you plan a strategy for tackling your technical debt, and we’ll show you how to make SonarQube a part of your routine rather than something extra you have to remember to do. We’ll guide you in twiddling SonarQube’s knobs so you can tune it to get the best experience in your environment. And finally, in case you feel the need, we’ll show you how to get started writing your own SonarQube plugin.

Over and over, I’ve seen this in action: good programmers are passionate about quality code. Show us what the problems are, and we’ll be almost compelled to fix them. In the past, the hard part has been pinpointing the problems. With SonarQube, the only hard part is finding the time to deal with them. Code quality used to be hard. Now it’s easy. Welcome to SonarQube.

ANN CAMPBELL