TL;DR overview
- Quality code treats every logical unit—functions, classes, modules, and services—as a component with clear responsibilities, well-defined interfaces, and minimal coupling to other components.
- Poorly defined component boundaries lead to tangled dependencies, making code harder to test, maintain, and evolve; static analysis can surface these issues as code smells and complexity metrics.
- SonarQube measures component-level health through cyclomatic complexity, cognitive complexity, and dependency metrics, giving teams actionable signals about structural code quality.
- Applying component thinking to new code—rather than retroactively fixing legacy systems—is the most sustainable path to a maintainable codebase at scale.
Something occurred to me recently that I wanted to share. Sometimes I'm late to the party, so this may have been obvious to you all along, but it didn't jump out at me at first, so I thought it might be worth talking about. It's the fact that the Views plugin turns a project into just another component.
If you're familiar with the Components view, then you know it shows you the "child" resources of the current resource. If you're starting from a project, that might be a list of modules, packages, or classes, or potentially a jumble of all three (although that sounds like a confusing project organization to swim through). Here's the components view of the SonarQube Server project itself:
Similar to a measures filter, the columns on the right are configurable, although unlike in a filter, you can't remove the name or the alert column.
The first row, the separate one at the top, is the current component. The ones below it are the child components. Each name is linked, and for files, the link will pop open a component viewer. For everything else, the link drills in to the component so that you land at a page where the component you clicked on is in the top row and below it are its children.
That's cool enough - the ability to easily see all the files in a package, for instance. But what I think is really neat about the component viewer is that all the left side navigation links are still in place. So when you've drilled into a module or a package, you've still got a "Dashboard" link on the left. A working dashboard link.
It doesn't just take you to the project's dashboard. That wouldn't be cool enough. No, it takes you to the component's dashboard.
Here you can see almost all the same details on a sub-set of a project that you're used to seeing at the project level: lines of code, issue counts, unit test data, and so on. The one tiny caveat is that history data isn't retained for packges/directories by default. You can turn that on if you like, but be aware that it may bloat your database.
The bread crumb trail tucked just under the main menu options shows you how far you've drilled, and you can use it to climb back up if you like.
But I started with the Views plugin. What does all this have to do with the Views plugin? Well, just like SonarQube Server's default handling of components means you have access to the "layers" under a project, the Views plugin allows you to stack layers on top of your project. It lets you treat projects like directories and aggregate them into arbitrary collections.
If you've got an application that's made up of multiple SonarQube Server projects, it can be hard to get a consolidated view of the application's quality. I've tried it with spreadsheets, and believe me, its tedious, error-prone, and a pain in the patoot. The Views plugin allows you to group those projects directly within SonarQube Server and get the same dashboard for the aggregate application that you have for the individual projects.
And setting that up is easy. Once the Views plugin is installed, you get the same sort of intuitive interface SonarQube Server gives you for pretty much everything else. It lets you cherry-pick your projects, of course - "manual" mode is the default. But it also lets you create views by language (all C#, for instance), or manual measure, or by regular expression (name or project key).
But it gets better. Let's say you're a manager with multiple applications in SonarQube Server. There's the one you've just finally gotten a consolidated look at with your first view, and then there are a handful more projects that each encompass an entire application. Are you back to spreadsheets for an aggregated view of your whole portfolio? Nope. Because your view is just a component.
Let's say you started out knowing you'd want a team-level view. Your first step was to create that view and include all the projects that represent whole applications. Next, you added a sub-view for your multi-project application and added its projects.
Now you've got a team-level view of application quality, and just like you can drill in to the components at the project level, you can drill in to the sub-views and projects in your view.
The same process happens to let your boss roll your team view up with those of your peers' and have her own consolidated picture. Here's what that looks like in nemo:
You're looking at the dashboard for the Forge view, which is an aggregation of all the organization-level views in nemo. It's kinda small, but the arrow is pointing to the tree map block for Apache, which is a view of all the Apache Software Foundation projects. Just like you can drill in to see a project's components, you can drill in to see a view's in exactly the same way.
Developers are used to thinking of software as sets - sets of files collected into packages, sets of packages collected perhaps into modules, and then the modules into applications. Out of the box, SonarQube Server gives you full access and visibility into those sets. Add in the Views plugin and you can make bigger sets.
You're no longer constrained by the line between where one application ends and another begins. If it makes business sense to consider them together, then by all means, have at it. Because you're no longer constrained by what made sense to the developers. Now you can look at quality based on the business logic.