Why component-level code quality matters
Repository-wide quality numbers average away the problems teams need to see. Why per-component metrics and ownership work better, and how Sonda approaches them.
Most code quality dashboards answer one question about a repository: how is it doing overall? In a monorepo shared by several teams, that's rarely the question anyone needs answered. This article argues for looking at quality per component, and describes what Sonda does about it today. The argument is opinion; the description of Sonda is what 0.1.0 ships.
An average hides its outliers
Take a repository with two parts. These numbers are illustrative, not measured:
| Component | Lines of code | Open issues | Issues per 1,000 lines |
|---|---|---|---|
services/ |
90,000 | 45 | 0.5 |
scripts/ |
5,000 | 60 | 12.0 |
| Total | 95,000 | 105 | 1.1 |
The repository-wide figure, 1.1 issues per thousand lines, looks healthy. scripts/ has twenty-four times the issue
density of services/, and the total says nothing about it. Every average does this: the bigger, steadier parts set
the number, and the small part going wrong disappears into it.
The same happens over time. If one team pays down debt while another adds it, the repository's trend can stay flat while both stories go untold.
A number needs an owner
"The repository has 412 days of technical debt" is true and hard to act on: nobody owns all of it. "scripts/ has 60
open issues and no owner" is a task, and it raises the right question.
Ownership usually already exists in a form tools can read: the CODEOWNERS file that GitHub, GitLab and other forges use to request reviews. Using it for quality data too means the person asked to review a change is also the person who sees the quality of the code they're responsible for.
Gate changes, then look at components
A per-component view isn't a replacement for a quality gate. They answer different questions:
- The gate asks whether a change makes things worse. It's about the next merge, and it should be strict about new code. See understanding quality gates in CI/CD.
- The component view asks where the existing problems are, and whose they are. It's about planning: which team pays down which debt.
How Sonda approaches it
On the Sonda server, a component is a project's top-level directory. Each one gets its own languages, size, open issues by severity, debt, eight-week trend and files, and an owner: whoever owns most of its files in CODEOWNERS. The Components screen lists them across projects, most issues first, filterable by owner. Component-level code analysis has the details.
It's deliberately simple, and that comes with limits:
- Top-level directories only. In a layout like
services/checkoutandservices/ledger, both are one component until Sonda learns to read workspace definitions (go.work, Cargo and pnpm workspaces). - No per-component gate. The gate judges the whole project.
- No dependency graph. Sonda doesn't record which component uses which.
Even so, top-level directories match how many repositories are actually laid out, and CODEOWNERS is often already there. Splitting the numbers along those lines takes no configuration and answers the question teams ask most: what's wrong in the code I own?