Każda lista „must-have tools for code quality” zaczyna się tak samo. SonarQube. Branżowy standard. Quality Gates. Technical Debt. Cognitive Complexity. Sześć tysięcy wbudowanych reguł.

Polemika z hype’em, oparta na realnym stacku produkcyjnym

---

Wszystko prawda. I wszystko nieistotne — dla większości projektów, które dziś naprawdę powstają.

W projekcie reads podjąłem decyzję, żeby nie używać SonarQube. Nie z lenistwa, nie z oszczędności, tylko po świadomej analizie. Ten artykuł to obrona tej decyzji — ale też uczciwa lista rzeczy, które się przy okazji traci. Bo polemika bez przyznania racji drugiej stronie jest tylko marketingiem na opak.

Mit „branżowego standardu”

Zacznijmy od najczęściej powtarzanego argumentu: „SonarQube to branżowy standard, więc trzeba go mieć”.

To zdanie ukrywa kilka rzeczy. Po pierwsze — który SonarQube? Bo Sonar to nie jest jeden produkt. To rodzina:

• Community Build (dawniej Community Edition) — darmowy, open-source
• Developer Edition — od około 2500 USD/rok przy najmniejszej puli linii kodu
• Enterprise Edition — wycena indywidualna, kilka razy więcej
• SonarQube Cloud — SaaS, od 32 USD/miesiąc za 100k LOC

Kiedy ktoś mówi „u nas Sonar wykrył”, to w 90% przypadków mówi o Developer Edition lub wyżej. Bo Community Build — ten darmowy, „branżowy standard” — w 2026 roku nie ma branch analysis i nie ma PR decoration. Nie wchodzi do pull requesta. Nie pokazuje wyników w GitHubie. Developer ma chodzić na osobny dashboard.

Według analizy z marca 2026 dla zespołów używających workflow opartego na pull requestach (czyli praktycznie każdego współczesnego zespołu) Developer Edition jest minimalną sensowną opcją, bo bez branch analysis i PR decoration findings Sonara po prostu giną — programiści ich nie widzą.

Innymi słowy: darmowa wersja Sonara w 2026 jest narzędziem do okresowego audytu, nie do code review. A płatna kosztuje minimum 2500 USD rocznie i wymaga własnego serwera albo subskrypcji SaaS.

To nie jest „darmowy branżowy standard”. To jest funnel sprzedażowy.

Co realnie pokrywa Sonar — i czym to zastąpić

Funkcje, dla których ludzie sięgają po Sonara, dzielą się na pięć kategorii. Sprawdźmy każdą.

1. SAST — wykrywanie podatności bezpieczeństwa

Sonar Community Build: podstawowe security checks, bez taint analysis, bez śledzenia przepływu danych. Sonar Developer+: zaawansowany SAST z taint analysis (SQL injection, XSS, niebezpieczne dane).

Tu zaczyna się pierwszy nieprzyjemny fakt: Community Build w ogóle nie skanuje pod kątem podatności w sposób, który dziś nazwałbyś SAST-em. Kategoria „Security Hotspots” jest, ale to są podpowiedzi typu „tu jest hasło w stringu, sprawdź sam”. Prawdziwy taint flow analysis jest w wersji płatnej.

Alternatywa GitHub-native: CodeQL.

CodeQL należy do GitHuba, jest darmowy dla publicznych repo i tani dla prywatnych (lub w ramach GitHub Advanced Security). Wykrywa SQL injection, XSS, path traversal, deserialization issues, hardcoded secrets — z taint analysis i cross-file flow. Wyniki lądują w zakładce Security w repo i blokują merge przez branch protection rules.

Specjaliści od bezpieczeństwa aplikacji często stwierdzają, że Sonar jako SAST jest słabszy od dedykowanych narzędzi typu Semgrep, Checkmarx czy Snyk Code, a CodeQL należy w ich opinii do tej drugiej kategorii — bo robi głęboką analizę semantyczną.

Wniosek: w obszarze SAST CodeQL bije Sonar Community Build na głowę i jest porównywalny lub lepszy od Sonar Developer Edition. Za zero złotych.

2. Linting i code smells

Sonar: około 6000 reguł, w tym dla TypeScript/JavaScript. Alternatywa: Biome (lub ESLint + Prettier, jeśli ktoś jeszcze chce mieć oddzielne narzędzia).

Biome zastąpił mi ESLinta i Prettiera w jednym, jest napisany w Rust i działa kilkadziesiąt razy szybciej. Reguły są mniej liczne niż w Sonarze (kilkaset vs sześć tysięcy), ale w 2026 to nie jest problem, bo:

• większość reguł Sonara dla popularnych języków pokrywa się z tym, co robi linter,
• Biome działa w pre-commit hooku, w IDE w czasie rzeczywistym i w CI — feedback loop jest sekundowy, nie minutowy,
• co jest naprawdę unikalne (cognitive complexity), zaraz omówię osobno.

Wniosek: dla typowego projektu webowego Biome wystarcza. Sonar tu nie wnosi przewagi, którą czułbyś w codziennej pracy.

3. Code coverage

Sonar: raportuje pokrycie testami, ale samego testowania nie robi — i tak musisz mieć Vitest, Jest czy coś. Alternatywa: Vitest + Codecov (lub Coveralls).

Codecov pokazuje pokrycie w PR, ma historyczny dashboard, robi flagi dla różnych części projektu. Robi dokładnie to samo, co Sonar w tej kategorii. Często lepiej.

4. Skanowanie sekretów i kontenerów

Sonar Community Build: brak. Advanced Secrets Detection jest tylko w Developer Edition+. Alternatywa: Gitleaks (sekrety) + Trivy (kontenery, dependency scanning, IaC).

Tu Sonar nawet nie wchodzi do gry w darmowej wersji. Gitleaks i Trivy razem dają więcej niż Sonar Developer Edition w tym obszarze.

5. Quality Gate i Technical Debt Dashboard

Sonar: centralny dashboard z metryką „dni długu”, trendy historyczne, quality gate blokujący merge. Alternatywa GitHub-native: branch protection rules + status checks + CodeQL severity gates.

I tutaj — uczciwie — Sonar wygrywa. Tej jednej rzeczy nie zastąpisz prosto narzędziami GitHub-native.

Co naprawdę tracisz bez Sonara

To jest sekcja, której większość artykułów typu „Sonar vs X” nie pisze. A powinna.

Cognitive Complexity w wersji Sonara

Sonar wprowadził (white paper G. Ann Campbell, 2018) metrykę Cognitive Complexity, która zastąpiła starszą Cyclomatic Complexity. Liczy zagnieżdżenia, breaki w logice, ternary expressions w bardziej „ludzki” sposób. Stała się nieformalnym standardem.

Biome ma noExcessiveCognitiveComplexity z prostym progiem. ESLint ma complexity (cyclomatic). To nie jest to samo. Jeśli twój zespół ma kulturę „CC > 15 nie wchodzi do mastera”, Sonar to zrobi precyzyjniej.

Detekcja duplikacji kodu między modułami

Sonar skanuje całe repo pod kątem powtarzających się bloków kodu (Sonar nazywa to „duplicated lines”). Biome tego nie robi. ESLint tego nie robi. CodeQL tego nie robi. Możesz dorzucić jscpd jako osobny krok w CI, ale to znowu narzędzie do utrzymania.

W projektach z wieloma wariantami (np. multi-domain, white-label) duplikacja jest realnym problemem długoterminowym. Bez Sonara musisz to łapać code reviewem.

Centralny dashboard długu technicznego

Quality Gate w Sonarze pokazuje: „ten moduł ma 12 dni długu, ten ma 3, trend rośnie”. GitHub Security tab pokazuje podatności. Codecov pokazuje coverage. Biome pokazuje bieżące błędy. Żaden z nich nie agreguje tego w jedną liczbę „ile dni pracy musi zostać włożone, żeby spłacić kod”.

Dla solo projektu albo dwuosobowego zespołu — bez znaczenia, bo i tak masz to w głowie. Dla zespołu pięcioosobowego utrzymującego kod trzy lata — to zaczyna mieć znaczenie. Dla regulowanej branży (banki, healthcare), gdzie audytor pyta „pokaż dashboard długu technicznego” — to jest realny powód, żeby Sonara mieć.

Standaryzacja Quality Gate między projektami

Jeśli masz pięć repozytoriów i chcesz, żeby wszystkie miały identyczny próg jakości (np. coverage > 80%, CC < 15, brak nowych code smells), Sonar to zrobi z jednego miejsca. GitHub-native wymaga skopiowania konfiguracji do każdego repo i utrzymywania jej w synchronizacji.

Tabela porównawcza

Funkcja	Sonar Community Build	Sonar Developer (~2500 USD/rok)	GitHub-native stack
SAST z taint analysis	nie	tak	tak (CodeQL)
Branch analysis / PR decoration	nie	tak	tak (natywnie)
Linting / code smells	tak (6000 reguł)	tak	tak (Biome, węższy zakres)
Code coverage w PR	tak	tak	tak (Codecov)
Skanowanie sekretów	nie	tak (advanced)	tak (Gitleaks)
Skanowanie kontenerów / IaC	nie	częściowo	tak (Trivy)
Cognitive Complexity (Sonar metric)	tak	tak	przybliżone (Biome)
Detekcja duplikacji	tak	tak	nie (chyba że dodasz jscpd)
Dashboard długu technicznego	tak	tak	nie
Self-hosting	tak (JVM + Postgres)	tak	nie wymagane
Koszt utrzymania	serwer + aktualizacje	serwer + licencja	zero infrastruktury

Argument, który rzadko pada: koszt utrzymania samego Sonara

Self-hosted Sonar to nie jest neutralny dodatek do CI. To:

• JVM (minimum 2 GB RAM dla Community Build, więcej w praktyce)
• PostgreSQL (oddzielna baza)
• regularne aktualizacje (Long-Term Active 2026.1 jest aktualną wersją LTA, najnowszy release to 2026.2 z marca 2026 — czyli upgrade’y są częste)
• backup bazy
• monitoring uptime
• jeden więcej Single Point of Failure w pipelinie

Na moim VPS-ie mam już n8n, Pihole, WireGuard, GitHub Actions Runner, Cloudflare Tunnel. Dorzucenie Sonara to nie jest decyzja architektoniczna o jakości kodu — to decyzja o dodaniu kolejnego stacka do utrzymania. I to stacka, który padnie pierwszy, jak zabraknie RAM-u.

Alternatywą jest SonarQube Cloud. Wygodniej, ale wtedy łamiesz zasadę „self-hostable, no extra SaaS” i płacisz subskrypcję od linii kodu.

Antifragile thinking mówi: usuń komponent, którego wartość krańcowa jest niższa niż koszt utrzymania. W projekcie reads Sonar tę poprzeczkę nie przekraczał.

Kiedy Sonar jednak ma sens

Polemika nie polega na tym, żeby udawać, że narzędzie jest bezużyteczne. Sonar ma sens w trzech przypadkach:

1. Regulowane branże z audytami zewnętrznymi. Bank, ubezpieczenia, healthcare, krytyczna infrastruktura. Audytor przychodzi i pyta o dashboard długu technicznego, raporty OWASP Top 10 w PDF, historyczne trendy quality gate. GitHub-native nie wygeneruje ci PDF-a dla audytora.

2. Zespoły 10+ osób z polyglot codebase. Java + .NET + Python + JavaScript + Go w jednym repo. Sonar obsługuje 35+ języków z jednym dashboardem. Dla zespołu, gdzie każdy zespół ma swój język, ujednolicenie metryk w jednym miejscu jest realnym zyskiem.

3. Migracje legacy z dużym długiem. Przejmujesz codebase z 10 lat, masz 50% pokrycia, nie wiesz od czego zacząć. Sonar wskaże ci najbardziej zadłużone moduły, posortuje po severity, da ci roadmapę. CodeQL + Biome takiej narracji nie zbudują.

W żadnym z tych trzech scenariuszy nie jestem ja w 2026 roku, więc Sonara nie używam.

Stack, który realnie zastąpił Sonara w projekcie reads

Dla porządku — co jest skonfigurowane w .github/workflows/:

• CodeQL (codeql.yml) — SAST, taint analysis, security severity gating
• Trivy — skanowanie kontenerów, dependency vulnerabilities, IaC misconfigurations
• Gitleaks — wykrywanie sekretów w commitach (pre-commit hook + CI)
• Biome — linting + formatting, w pre-commit i CI
• Vitest + Codecov — coverage z dashboardem PR
• Branch protection rules — wymagane status checks z wszystkich powyższych

Zero zewnętrznej infrastruktury. Zero subskrypcji SaaS poza darmowymi tierami. Cały feedback loop w GitHubie, gdzie programista i tak pracuje.

Wniosek

„Branżowy standard” to argument leniwy. SonarQube był standardem, kiedy alternatywą był ESLint w 2014 roku. W 2026 roku, kiedy GitHub kupił Semmle (CodeQL), uruchomił Advanced Security, a narzędzia natywne zintegrowały się z PR-ami — równanie się zmieniło.

Dla większości współczesnych projektów webowych, prowadzonych przez 1–10 osób, na nowoczesnym stacku z PR-based workflow, GitHub-native stack:

• wykrywa więcej podatności niż Sonar Community Build,
• daje szybszy feedback,
• nie wymaga oddzielnej infrastruktury,
• nie wymaga licencji,
• nie zmusza do kompromisu między „darmowy ale bezużyteczny w PR” a „płatny ale 2500 USD/rok”.

Tracisz dashboard długu technicznego, dokładną Cognitive Complexity Sonara, wykrywanie duplikacji i centralne quality gates dla wielu repo. Jeśli któreś z tych czterech jest dla ciebie krytyczne — Sonar (Developer Edition, nie Community) jest dobrym wyborem.

Jeśli nie — SonarQube w 2026 roku jest narzędziem, którego nie potrzebujesz, mimo że internet ci to powtarza.

---

Tekst oparty na decyzjach architektonicznych projektu reads. ADR 0011 („GitHub-native tools where possible; no additional SaaS”) zachowuje moc.