Jak SonarQube pomaga uporządkować Twój kod i dlaczego początkujący się go boją

Każdy programista przynajmniej raz uczestniczył w przeglądzie pull requesta innej osoby, szukając zapomnianych sprawdzeń null, wycieków zasobów i kodu wklejanego z innych miejsc. To wyczerpuje. Ludzie się męczą, przegapiają krytyczne podatności i kłócą się o formatowanie zamiast rozmawiać o architekturze.

Tutaj z pomocą przychodzi analiza statyczna. Projekt SonarQube od SonarSource od wielu lat pozostaje głównym standardem w tej dziedzinie. Repozytorium na GitHubie ma ponad 10 tysięcy gwiazdek, a narzędzie jest wdrożone na serwerach tysięcy zespołów na całym świecie.

Poznajmy bliżej, jak ten projekt działa od środka, jak uruchomić go lokalnie i dlaczego twórcy wprost proszą w README, aby współtwórcy nie zgłaszali nowych funkcji.

Co robi SonarQube

SonarQube to serwerowa aplikacja do ciągłej kontroli jakości kodu źródłowego. Analizator skanuje bazę kodu, szukając potencjalnych błędów, podatności bezpieczeństwa, duplikatów i zapachów kodu.

Główna idea autorów koncentruje się na koncepcji Clean Code i mechanizmie Quality Gate. Zamiast zalewać zespół milionami ostrzeżeń w starym legacy code, SonarQube koncentruje się na nowym kodzie. Zmieniasz trzy pliki w ramach zadania, a pipeline sprawdza jakość dokładnie tych zmian. Jeśli nowy kod nie spełnia zdefiniowanych kryteriów jakości (na przykład pokrycie testami poniżej 80% lub pojawiła się krytyczna podatność), build nie powiedzie się.

Narzędzie obsługuje dziesiątki języków programowania: Java, C#, C++, TypeScript, JavaScript, Python, Go, Kotlin i wiele innych.

Główne możliwości systemu

Narzędzie rozwiązuje cztery praktyczne wyzwania przy integracji z procesem deweloperskim:

1. Automatyczne wykrywanie podatności (Security Hotspots i Vulnerabilities). Analizator znajduje SQL injections, niebezpieczną deserializację, zakodowane hasła i tokeny. Podejrzane obszary są oznaczane do ręcznego przeglądu bezpieczeństwa.
2. Śledzenie długu technicznego i zapachów kodu. System szacuje przybliżony czas, jaki programista potrzebowałby na naprawę źle strukturyzowanych klas, nadmiernie skomplikowanych funkcji lub martwego kodu.
3. Śledzenie duplikacji kodu i pokrycia testami. SonarQube parsuje raporty z narzędzi do pokrycia (jak JaCoCo, Coverage.py czy lcov) i koreluje procent pokrycia z nowymi liniami.
4. Elastyczna konfiguracja reguł (Quality Profiles). Każdy zespół może włączyć surowe sprawdzanie dla krytycznych usług i poluzować reguły dla wewnętrznych narzędzi.

Repozytorium projektu zawiera również badge AI Code Assurance. Deweloperzy dostosowują reguły dla kodu generowanego przez AI, sprawdzając go pod kątem typowych halucynacji i ukrytych błędów.

Struktura repozytorium i budowania

Przeglądając kod źródłowy SonarQube, znajdujemy klasyczny enterprise'owy projekt Java. Budowanie lokalnie wymaga Java 17 i Git.

Ciekawe rozwiązanie: interfejs web jest wydzielony do osobnego repozytorium sonarqube-webapp. Podczas standardowego budowania backendu gotowy UI jest pobierany bezpośrednio z Maven Central jako zależność. Deweloperzy serwerowi nie muszą się zajmować Node.js, chyba że ich zmiany dotyczą frontendu.

Budowanie i uruchamianie lokalnie odbywa się standardowymi poleceniami Gradle:

# Клонируем репозиторий
git clone https://github.com/SonarSource/sonarqube.git
cd sonarqube

# Собираем проект (можно добавить -x test, чтобы пропустить тесты)
./gradlew build

Gdy build się zakończy, archiwum serwera znajduje się w folderze sonar-application/build/distributions/. Rozpakuj je i uruchom skrypt wykonywalny dla swojego systemu operacyjnego:

# На Linux
bin/linux-x86-64/sonar.sh start

# На macOS
bin/macosx-universal-64/sonar.sh start

# На Windows
bin\windows-x86-64\StartSonar.bat

Jeśli musisz wprowadzić zmiany zarówno w interfejsie, jak i backendzie jednocześnie, musisz sklonować część webową, zbudować ją za pomocą Yarn i przekazać ścieżkę do budowania do buildera:

cd /path/to/sonarqube-webapp/server/sonar-web
yarn && yarn build

cd /path/to/sonarqube
WEBAPP_BUILD_PATH=/path/to/sonarqube-webapp/server/sonar-web/build/webapp ./gradlew build

Nietypowe podejście do open source

W sekcji dotyczącej wkładu w projekt autorzy szczerze ostrzegają społeczność: projekt nie potrzebuje twoich pull requestów z nowymi funkcjami.

Twórcy tłumaczą to wprost. SonarSource ma ścisłą wewnętrzną mapę drogową i rygorystyczne wymagania architektoniczne. Zewnętrzny deweloper praktycznie nie jest w stanie się do nich dopasować. Dlatego maintainerzy akceptują od zewnętrznych współtwórców tylko poprawki literówek i drobne kosmetyczne zmiany, a sugestie dotyczące nowych funkcji kierują na forum społeczności.

Taką bezpośredniość spotyka się rzadko, ale oszczędza mnóstwo czasu deweloperom, którzy chcą zgłosić duży PR.

Praktyczne scenariusze użycia

Jak zespoły wdrażają SonarQube w realnej pracy:

• Osadzanie w pipeline CI/CD. Skaner uruchamia się podczas etapu budowania w GitLab CI, GitHub Actions lub Jenkins. Jeśli Quality Gate nie przejdzie, scalanie brancha jest automatycznie blokowane.
• Sanityzacja projektów legacy. Zespół oznacza stary dług techniczny jako bazę. Deweloperzy nie spędzają miesięcy na przepisywaniu starego kodu, ale każdy nowy commit podlega surowym standardom.

Kto powinien spróbować

SonarQube to dojrzałe, monumentalne narzędzie. Wdrażanie własnej instancji dla projektu hobbystycznego liczącego 500 linii nie ma większego sensu: łatwiej poradzić sobie z lokalnym linterem.

Ale jeśli pracujesz w zespole czterech lub więcej osób, piszesz w wielu językach i chcesz wyeliminować debaty o czystości kodu z code review, uruchomienie lokalnej lub serwerowej instancji SonarQube byłoby doskonałym rozwiązaniem. Narzędzie natychmiast ujawnia słabości architektoniczne i nie pozwoli na wprowadzenie wątpliwego kodu do produkcji.