Orchestrator/bahn/project-audit/analysis/sonarqube-deepdive.md

SonarQube Deep Dive — Code-Qualitaet pro Team

Stand: 2026-04-30 | Quelle: SonarQube (74 Projekte, nur master/main Branches)

---

1. Ueberblick

Team	Projekte	Lines of Code	Bugs	Smells	Smells/1K LoC	Coverage	QGate OK
Team 404	2	68.313	5	420	6.1	84.2%	0/2
Team CIB	15	121.727	7	2.535	20.8	78.2%	9/15
Team Zero	9	37.927	0	152	4.0	21.8%*	8/9
Shared Libs	6	4.877	2	50	10.3	0%	0/6
Andere/Infra	41	28.813	13	600	20.8	33.6%	29/41

*Zero Coverage-Durchschnitt verzerrt durch tadef-connector (27.6K Lines, 0% Coverage). Ohne tadef: 91.8% Coverage.

---

2. Detailanalyse pro Team

Team 404 (Portal) — 68K Lines, 2 Services

Service	Lines	Bugs	Smells	Coverage	QGate
portal-ui (Angular)	42.726	4	77	85.8%	ERROR
portal-middleware	25.587	1	343	81.4%	ERROR

Bewertung:

• Coverage ist gut (84-86%) — das Frontend-Qualitaetsproblem liegt NICHT an fehlenden Tests
• Portal-Middleware hat 5x mehr Smells als Portal-UI (343 vs 77) bei halb so viel Code
• Beide Services haben Quality Gate ERROR — vermutlich wegen Bugs (4+1=5)
• Kernaussage: Die hohe Bug-Rate (33% aus Jira) korreliert NICHT mit schlechter Coverage. Das Problem ist eher in der Testqualitaet (was getestet wird) als in der Testquantitaet (wie viel getestet wird).

Empfehlung:

• Portal-Middleware Smells reduzieren (343 bei 25K Lines = 13.4/1K — deutlich ueber Durchschnitt)
• Bug-Ursachen analysieren: Sind es Regressions-Bugs (Tests fehlen fuer Edge Cases) oder Integrations-Bugs?

Team CIB (Backend) — 122K Lines, 15 Services

Service	Lines	Bugs	Smells	Coverage	QGate
steuerung-vertrieb (SV)	93.146	3	2.214	81.6%	ERROR
auftrags-verwaltung-trasse	8.430	0	102	86.2%	OK
archivierungsservice	6.733	2	83	78.8%	ERROR
ifp-mock	4.917	2	66	50.4%	ERROR
kundendaten-bereitstellung	1.834	0	2	96.9%	OK
rabattnummern-bereitstellung	1.374	0	9	86.3%	OK
ifp-connector	1.318	0	5	84.9%	OK
auftrag-service-kafkamock	2.221	0	35	0%	ERROR
auftrag-service	949	0	19	0%	ERROR

Bewertung:

• SV ist das Sorgenkind: 93K Lines, 2.214 Smells (23.8/1K LoC!) — mit Abstand hoechste technische Schuld
• Aber: SV hat 81.6% Coverage und die Bug-Rate sinkt (36% → 9%) — die Smells verursachen keine Bugs
• Kleinere Services (KDV, Rabatt, IFP-Connector) sind vorbildlich: >85% Coverage, <10 Smells
• AV-Trasse: Gute Qualitaet (86.2% Coverage, 102 Smells bei 8.4K Lines)
• 2 Services ohne Coverage (Mocks) — akzeptabel fuer Mock-Services

Empfehlung:

• SV-Smells langfristig abbauen (Top-Regel S1192: 976 String-Duplikate — Refactoring-Kandidat)
• Archivierungsservice: 2 Bugs fixen, Coverage von 78.8% auf >85% bringen
• IFP-Mock: Coverage von 50.4% ist zu niedrig fuer einen Service der in Tests genutzt wird

Team Zero (TAF/TAP) — 38K Lines, 9 Services

Service	Lines	Bugs	Smells	Coverage	QGate
tadef-connector	27.646	0	99	0%	ERROR
stammdaten-bereitstellung	5.042	0	13	82.0%	OK
common-interface	4.056	0	37	93.8%	OK
taftap-tdm-konverter	6.586	0	26	90.6%	OK

Bewertung:

• 0 Bugs in allen Zero-Services — beste Qualitaet im Programm
• tadef-connector (27.6K Lines, 0% Coverage) ist der einzige Ausreisser — vermutlich generierter Code oder Legacy
• Ohne tadef: 4.0 Smells/1K LoC und 91.8% Coverage — Benchmark fuer andere Teams
• Common Interface: 93.8% Coverage bei SOAP-Schnittstelle — beeindruckend

Empfehlung:

• tadef-connector: Klaeren ob Coverage moeglich/sinnvoll ist (generierter Code?)
• Zero als Qualitaets-Benchmark beibehalten und Best Practices dokumentieren

---

3. Shared Libraries — 0% Coverage

Library	Lines	Smells	Coverage
core-components-kafka	1.567	24	0%
core-components-common	1.096	5	0%
signature-database	1.091	12	0%
signature-message	622	5	0%

Bewertung:

• Alle Shared Libraries haben 0% Coverage — das ist ein Risiko
• Diese Libraries werden von ALLEN Services genutzt — ein Bug hier betrifft das gesamte System
• Insgesamt nur 4.877 Lines — ueberschaubar

Empfehlung:

• DRINGEND: Tests fuer core-components-kafka und core-components-common schreiben
• Shared Libraries sollten die hoechste Coverage haben (>90%), nicht die niedrigste

---

4. Quality Gate Failures — Zusammenfassung

Grund	Projekte	Beispiele
Bugs > 0	8	portal-ui (4), SV (3), archivierungsservice (2)
Coverage = 0%	12	tadef-connector, Mocks, Shared Libs, Infra-Tools
Coverage < Schwelle	3	ifp-mock (50.4%), archivierungsservice (78.8%)

---

5. Korrelation: SonarQube vs. Jira Bug-Rate

Team	SonarQube Bugs	SonarQube Coverage	Jira Bug-Rate (90d)	Korrelation?
404	5	84.2%	33% (steigend)	NEIN — hohe Coverage, trotzdem viele Bugs
CIB	7	78.2%	20% (sinkend)	TEILWEISE — niedrigere Coverage, aber Bug-Rate sinkt
Zero	0	91.8%*	15% (stabil)	JA — beste Coverage = wenigste Bugs

Fazit: Coverage allein erklaert die Bug-Rate nicht. Team 404 hat gute Coverage (84%) aber die hoechste Bug-Rate. Das deutet auf:

1. Testqualitaet — Tests pruefen nicht die richtigen Szenarien (Edge Cases, Integration)
2. Frontend-Komplexitaet — Angular-UI hat andere Fehlerquellen als Backend (State Management, Async, Browser-Kompatibilitaet)
3. Fehlende E2E-Tests — Unit-Tests allein reichen nicht fuer Portal-Qualitaet

---

6. Top-Empfehlungen (priorisiert)

1. Shared Libraries testen (DRINGEND) — 0% Coverage bei Code der ueberall genutzt wird. Risiko: Ein Bug hier betrifft alle Services.

2. SV-Smells systematisch abbauen — 2.214 Smells, Top-Regel S1192 (976 String-Duplikate). Sprint-weise 50-100 Smells pro PI reduzieren.

3. Portal: Testqualitaet statt -quantitaet — Coverage ist gut (84%). Problem sind fehlende Edge-Case-Tests und E2E-Tests. Empfehlung: Playwright/Cypress fuer kritische User Flows.

4. tadef-connector klaeren — 27.6K Lines ohne Coverage. Ist das generierter Code? Wenn ja: aus SonarQube-Metriken ausschliessen. Wenn nein: Tests schreiben.

5. IFP-Mock Coverage erhoehen — 50.4% ist zu niedrig fuer einen Mock-Service der in Integrationstests genutzt wird.