W ramach podnoszenia jakości kodów zdecydowaliśmy się na uruchomienie SonarQube dla naszych projektów. Oczywiście początki okazały się trudne, bo jak każda nowość również statyczna analiza kodów na początku wydaje się być przeszkodą a nie pomocą. Jednak praktyka pokazuje, że była to bardzo dobra decyzja. Sporą ilość czasu poświęconą na konfigurację i wstępne wyczyszczenie kodu wynagradza z nawiązką wymuszanie dobrych standardów, jak również czasami wykrywanie błędów w kodzie. Chciałbym pokrótce opisać co uruchomiliśmy w naszym projekcie i jak osiągnęliśmy użyteczność narzędzia.
Pierwsze kroki
W tej części nie chcę się zajmować technicznymi aspektami instalacji – są one opisane w wielu miejscach. Instalacja samego SonarQube nie jest problemem. Zainstalowany na build serwerze, zintegrowany z buildami TFS. Build się uruchamia, pojawiają się pierwsze wyniki analiz. Trochę zabawy z uruchomieniem integracji SCM, ale i to udaje się rozwiązać. Serwer jest zainstalowany, podczas każdego build-a pojawiają się statystyki.
Po krótkiej chwili radości z posiadania nowego narzędzia przychodzi zimny prysznic. Pomimo, iż projekt był rozpoczynany z wysokimi standardami jakości ilość raportowanych problemów jest spora. Rozpoczynaliśmy z unit testami, mamy nowoczesną architekturę a tu code smells liczone w setkach i Quality Gate czerwone. A miało być tak pięknie…
Nie jest dobrze 😉
Po dłuższym zastanowieniu przychodzi konkluzja – jeśli narzędzie ma być użyteczne, to trzeba jakoś doprowadzić do stanu, żeby szum informacyjny zamienić na użyteczne informacje. Tu krótka dygresja – oczywiście bardzo pomaga zainstalowanie SonarQube w momencie rozpoczęcia projektu. Jeśli uruchomimy analizę statyczną kodu na dalszym etapie projektu, to trzeba się liczyć z dużą ilością błędów. Ale nawet w tym przypadku warto, jedynie QualityGate należy dopasować, aby reagowały na nowo stworzone kody, pomijając błędy w już istniejących. K
W naszym przypadku pojawiły się 2 duże kategorie problemów:
- Błędy związane ze specyfiką technologii
- Błędy związane z faktycznymi niedoskonałościami w kodzie źródłowym
Błędy związane ze specyfiką technologii
Przykładem takiego problemu jest na przykład metoda render() w React. Trudno sobie wyobrazić dzielenie funkcji render() na małe kawałki, a SonarQube cały czas zgłasza zbyt dużą złożoność funkcji lub zbyt długą funkcję. Można tu wyłączyć specyficzny typ reguły w konkretnych plikach. Czyli np. javascript:FunctionComplexity jest wyłączone w plikach **/*Component.js (komponenty React mają takie nazwy).
Błędy związane z faktycznymi niedoskonałościami w kodzie źródłowym
Tutaj postępowanie podobne – lepiej wyłączyć tymczasowo jakąś regułę i później w kolejnych sprintach poprawiać kody źródłowe, niż funkcjonować z błędami liczonymi w setkach – nikt nie będzie zwracał uwagi na alerty z SonarQube. Więc kilka reguł zostało globalnie wyłączonych, a reszta błędów uznanych za ważne została poprawionych. Teraz stopniowo w kolejnych sprintach bierzemy kolejną regułę i po włączeniu staramy się wyczyścić kody źródłowe.
Podsumowanie
SonarQube jako narzędzie oddaje nieocenione usługi ale uruchomienie go tylko po to, żeby działał nie przyniesie efektów. Należy połączyć to z wysiłkiem doprowadzenia projektu do stanu QualityGate: Passed nawet za cenę wyłączenia/dostosowania pewnych reguł. Mając na uwadze stopniowe doprowadzanie kodu do faktycznego stanu. Czego wszystkim życzę 😉