Zum Hauptinhalt springen

📊 SonarQube – Codequalität messbar machen

SonarQube ist eine Plattform zur statischen Codeanalyse mit Fokus auf:

  • Code Smells
  • Bugs
  • Security Vulnerabilities
  • Maintainability
  • Technical Debt
  • Testabdeckung

Während Linting lokale Regeln prüft, bewertet SonarQube die strukturelle Codequalität auf Projektebene.

1. Ziel und Einordnung​

1.1 Was macht SonarQube?​

Sonar analysiert den gesamten Codebestand und klassifiziert Findings typischerweise in:

  • Bug (wahrscheinlicher Fehler)
  • Vulnerability (Sicherheitsrisiko)
  • Code Smell (Wartbarkeitsproblem)
  • Security Hotspot (manuelle Prüfung erforderlich)

Zusätzlich berechnet Sonar:

  • Test Coverage
  • Duplications
  • Cognitive Complexity
  • Maintainability Rating
  • Reliability Rating
  • Security Rating
  • Technical Debt

Sonar liefert damit ein Qualitätsprofil – kein binäres „gut/schlecht“.

1.2 Was macht SonarQube nicht?​

Sonar:

  • versteht keine Geschäftslogik
  • ersetzt kein Code Review
  • ersetzt keine Architekturarbeit
  • erkennt nicht jedes Sicherheitsproblem
  • ist kein Ersatz für Penetration Tests

Es ist ein automatisierter Indikator – kein Garant für Qualität.

2. Quality Gates​

Sonar arbeitet mit sogenannten Quality Gates.

Ein Gate kann definieren:

  • Keine neuen Bugs
  • Keine neuen Vulnerabilities
  • Coverage auf neuem Code ≥ X %
  • Keine neue Duplication
  • Keine Major Issues auf neuem Code

Wichtig:

Quality Gates sollten sich primär auf New Code beziehen.

Alte technische Schulden dürfen nicht jede Weiterentwicklung blockieren.

3. Harte vs. weiche Konfiguration​

Sonar kann sehr streng konfiguriert werden:

  • Fail bei jeder Minor Issue
  • Mindest-Coverage global
  • Keine Duplication toleriert

Das ist technisch möglich –
aber organisatorisch nicht immer sinnvoll.

Empfehlung​

  • Streng bei Security & Bugs
  • Realistisch bei Maintainability
  • Fokus auf New Code
  • Schulden sichtbar machen, nicht verstecken

4. Umgang mit Findings​

Der entscheidende Punkt ist nicht die Konfiguration –
sondern der Umgang mit Ergebnissen.

4.1 Nicht ignorieren​

Findings sollten:

  • entweder behoben
  • oder bewusst akzeptiert
  • oder technisch begründet „Won’t Fix“ markiert werden

Ignorierte Findings erzeugen:

  • schleichende Qualitätsverschlechterung
  • sinkendes Vertrauen in das Tool
  • Gewöhnung an rote Dashboards

4.2 Security Findings sind besonders kritisch​

Sonar erkennt z. B.:

  • SQL Injection Risiken
  • unsichere Deserialisierung
  • unvalidierte Eingaben
  • gefährliche Regex
  • unsichere Kryptonutzung

Diese sollten niemals pauschal ignoriert werden.

Security Hotspots müssen geprüft und dokumentiert werden.

4.3 „Legacy ist halt so“ ist keine Strategie​

In bestehenden Systemen findet Sonar oft:

  • tausende Code Smells
  • hunderte Security Issues
  • hohe Komplexität

Hier gilt:

  • Baseline definieren
  • Fokus auf neuem Code
  • Schrittweise Reduktion planen

5. Sonar im Projektlebenszyklus​

5.1 Von Anfang an integriert​

Wenn Sonar früh aktiv ist:

  • keine Altlasten
  • saubere Baseline
  • klare Kultur
  • kein Big-Bang-Aufräumen

Späte Einführung ist deutlich schwieriger.

5.2 Stufenmodell-Kontext​

Stufe 1:

  • optional, lokal

Stufe 2:

  • Sonar als CI-Analyse
  • Gate auf neuem Code

Stufe 3:

  • Security & Reliability strikt
  • Komplexitätsgrenzen sinnvoll gesetzt

Stufe 4:

  • dokumentierte Behandlung von Findings
  • Evidence für Audits

Stufe 5:

  • vollständige Nachweisbarkeit
  • Integration in Compliance-Dokumentation

6. Typische Anti-Patterns​

  • Gate komplett deaktivieren
  • Alle Issues auf „Won’t Fix“
  • Coverage künstlich erhöhen
  • Komplexität ignorieren
  • Sonar nur als KPI benutzen

Sonar ist kein Management-Dashboard zur Bewertung von Entwicklern.

Es ist ein Risikofrühwarnsystem.

7. Technische Schulden sichtbar machen​

Sonar quantifiziert Technical Debt.

Das ist kein Selbstzweck.

Es hilft bei:

  • Budgetargumentation
  • Priorisierung
  • Refactoring-Planung
  • Risikoabschätzung

Technische Schulden sind nicht per se schlecht.
Unbewusste Schulden sind gefährlich.

8. Definition of Done​

Ein Change gilt nicht als fertig, wenn:

  • neue Bugs oder Vulnerabilities entstehen
  • Quality Gate rot ist
  • Findings nicht bewertet wurden
  • Security Hotspots ungeprüft bleiben

Kernaussage​

SonarQube ist kein Kontrollinstrument gegen Entwickler.

Es ist ein Frühwarnsystem für:

  • Wartbarkeitsrisiken
  • Sicherheitsprobleme
  • schleichende Komplexität
  • technische Schulden

Richtig eingesetzt verhindert es nicht Entwicklung –
es verhindert Qualitätsverfall.