In this blog, I will share the story of how I got introduced to SonarQube and made use of it as a team lead. I will explain how it helped us improve our code, and also assisted me in growing a team of junior developers with a Clean Code companion by their side. I will share the mistakes we made in the process of learning how to work with this tool and share my advice with you who might find yourself in the same position as I was.
Developing an application can be a complicated task
We all know growing as a developer is a never-ending journey. We constantly have to learn new things. Personally, I love it! But it can be overwhelming sometimes. Looking back at the beginning of my career, I realize how much I had to learn: modern javascript, ECMAScript, React, asynchronous programming, CSS, Sass, flexbox, grids… The list goes on. As I gained more experience, I got to dive deeper into functional programming, CSS in JavaScript, high-order components, performance profiling, and more.
One of the most satisfying parts of being a developer is building cool user experiences while learning a wide range of technologies in parallel! This has always motivated me to go further and dig deeper, and eventually helped me understand how frontend software really works.
While the learning journey is highly rewarding, it can be difficult to master all languages and technologies required to develop an application. Personally, I always had the feeling that I was missing a tool to help me take my learning to the next level. A tool that would measure the quality of my code and point out potential errors, bad patterns, and vulnerabilities. But I’ve been lucky. I’ve always been surrounded by talented developers that were able to help me spot imperfections in my code during code reviews. They’ve been the ones to help me understand how to fix my code and improve as a developer.
How I was introduced to SonarQube
Two years ago, I became a front-end engineering manager responsible for a team of six front-end developers. I quickly realized that everyone on my team had to go through the same learning journey I’d been through, which brought into focus how much rigor crafting a good web application requires. Not only do technologies and tools need to be used correctly but the application must remain maintainable at all times. This gets even harder if you think about the need for the code to be understandable by everyone, with their own experience.
To achieve this level of rigor, we had code reviews, knowledge-sharing syncs between peers, and a tech lead “council” to define best practices and ensure team alignment. But even with all of these ceremonies, a big gap in the quality of our applications still remained. To make matters more difficult, our development force was spread across different teams and cities. Luckily, our base team in charge of the security, metrics, tooling, and the CI/CD setup introduced us toSonarQube.
The security team completed the configuration and we added a sonar.properties file to automatically spin up an instance and include the analysis in the release process. At that moment, we didn’t talk about how the product would be used, how it would work, or what was the philosophy behind it. But after adding SonarQube to our development workflow, we quickly realized it would be much more than a security gateway in our process.
Our first steps with SonarQube
The first few days using SonarQube were filled with a lot of emotions. Some developers panicked. Some were against the tool. Others believed some rules were incorrect and that they knew better than the tool. But in this time of uncertainty, the team came together to discuss the pros and cons of the different rules available. We uncovered why it was important to avoid magic numbers, to limit the cognitive complexity of a function, what is the right limit for complexity, etc. We also discussed frontend-specific needs: Should we really put route paths in constants? Avoid hard-coded values? But does that apply to style?
After days of dialogue within the team, we decided to build our own quality profile, one that made sense for us. This way, we could integrate all of our recent discussions into a team quality profile that we’d all share and use. We also agreed that Sonar’s analysis was informative and it helped us create processes for addressing issues that it detected.
The profile made the team feel more confident in moving forward with the tool. As our visibility across the codebase grew, we uncovered many things we would have probably missed during PR reviews. Also, we were able to discuss the coding rules behind every issue. This enabled beginner developers to learn faster. By questioning whether or not they should fix the problem, they would first have to understand why the rule exists and what it is trying to prevent.
What SonarQube quickly improved in our team
I quickly understood how much developers care about the quality of the code they write. In fact, not a single developer on my team would ever disregard the analysis results. Even when they felt frustrated when the results wouldn’t be good enough, developers would act right away to improve their PR. I believe every developer wants to deliver high-quality code. It’s just a matter of being given the right tool and right space for discussion.
With SonarQube, we had all the metrics we needed to assess the quality of our code. We knew which parts were clean, and which parts we had to improve. The tool helped us prioritize the efforts together with the project manager. They had access to the results and were able to understand if their product was at risk or not.
We also started using the code smells page to create onboarding tickets for new joiners (or even to add to smaller sprints) which was very well received. It allowed new joiners to start with something very precise and easily measurable.
Armed with SonarQube usage metrics, I was able to share our results with our internal tech lead council and listen to how other teams used it. We took this as an opportunity to align on a set of best practices to share across teams.
What mistakes we made in using SonarQube
We began our Clean Code journey with a decision that Sonar analysis was only going to be informative. And that was a huge mistake! We installed SonarQube without enough knowledge of how it’s meant to be used.
I wish I had known about the Clean as You Code methodology before! It was only when I joined Sonar that I learned about it and discovered how powerful it was. Obviously, when you have hundreds or thousands of bugs, security vulnerabilities, and code smells, it can be discouraging to try to fix them all. That’s where Clean as You Code helps!
Instead of investing substantial time and energy in fixing your legacy code, you can focus on making your new code clean. This way, you are not adding more issues to your codebase.
The quality gate prevents you from merging code that’s not clean and de facto helps you make sure no critical issue is added to the code base. At the same time, as you write new code, you inevitably touch old code. Simply because in the process of implementing new features, you will either remove some code (replacing it with the new one), or you will modify it to fit the needs of this new functionality. On average you rewrite 20% of your application code every year. With good settings and a good understanding of the tool, it shouldn’t be painful to increase the code quality of your application.
Put your trust in SonarQube!
We made many mistakes in our effort to learn how to work with SonarQube. We were a team of junior developers (and I was a junior engineering manager) with no experience with Clean Code solutions. Our introduction to SonarQube was a real opportunity for us to establish strong technical foundations and have many interesting discussions. It resulted in new guidelines and metrics for the team that helped create alignment on our Clean Code strategy with project stakeholders. By defining and enforcing our quality profile with a set of rules that made sense for us, we improved the overall quality and consistency of our code. At a personal level, SonarQube has also been an opportunity for me to spend more time and energy on the team dynamic and ambiance, and less on the technical aspects.
It took many attempts, discussions, and errors for us to figure out how to use SonarQube. Now that I work at Sonar, I realize how we could have leveraged the quality gate and the Clean As You Code methodology to go further. But hey, nobody gets to learn without failing first. So here is my advice for you - developer or development team - who is starting with SonarQube:
- Don’t see SonarQube as one more statistic about your code, instead embrace the Clean Code approach to yield the best results.
- Take advantage of the quality gate to ensure that the new code you write today is clean and empower developers to own the quality of their code.
- Discuss and define a meaningful quality profile with the right set of rules that makes sense to your team. The SonarWay is the best-preferred way to start.
- Finally, align everyone on your clean code strategy from the beginning by sharing metrics with all stakeholders.