Sonar reklamuje się obsługą Kotlina, ale co reklamy i dokumentacja przemilczają, to bardzo niska użyteczność sugestii, jakie oferuje dla tego języka.
Jeśli ktoś nie wie, o co chodzi: to popularne narzędzie do znajdowania problemów w kodzie. W marketingu pojawia się też jako SonarQube i SonarCloud. Ma opinię sprawdzonego „industry standard”. Jest duża szansa, że jeśli ktoś rzuci problem „potrzebujemy narzędzia do static analysis”, to od razu padnie sugestia „weźmy Sonara”. Czy słusznie? To zależy. Jeśli stawiamy na Kotlina, to nie.
W dalszej części artykułu skupię się na konkretnym zastosowaniu Sonara: do projektów napisanych w Kotlinie. Jeśli szukacie informacji jak odpalić SonarQube dla Javy – przykro mi, nie tu. Co jeszcze będzie? Podam linki, dzięki którym samodzielnie zweryfikujecie aktualną sytuację (nawet w wypadku, gdybym przestał aktualizować ten artykuł). Podzielę się też subiektywnymi wrażeniami o tym, jak deweloperzy i deweloperki Sonara radzą sobie z problemami w integracji z Gradle’em.
Spis treści
Moja historia z Sonarem
Wyjaśnijmy najpierw, że nie mam uprzedzeń. Sonar poznałem w jednej z pierwszych firm, w jakich pracowałem, i szybko zacząłem traktować go jako coś oczywistego, jak Jenkinsa i Jirę. Bardzo dużo nauczyłem się wtedy o wydajności i dobrych praktykach w Javie przez przeglądanie problemów znalezionych przez Sonar. Zwłaszcza przydatne dla rozwoju było to, że narzędzie miało wbudowane wyjaśnienie powodu uznania kodu za „zły”, odwołujące się do standardów języka i pokazujące konsekwencje.
Irytowało mnie też czasem, że Sonar czepiał się kodu, który nie powodował wprost problemu, ale łamał jakąś odgórną konwencję. Ja zaś nie miałem uprawnień, żeby wyłączyć w konfiguracji rzeczy, z którymi się nie zgadzałem. Tyle, że nie była to wina samego narzędzia.
Ogólnie więc wrażenia miałem może nie entuzjastyczne, ale umiarkowanie pozytywne.
Sonar dla Kotlina ma niewiele z Sonara dla Javy
Jednak przez ostatni czas pracowałem z projektami napisanymi w Kotlinie i byłem kompletnie rozczarowany raportami Sonara. Praktycznie zawsze widziałem komunikat „Sonar found no problems” – niezależnie, czy przechodząc do code review widziałem kod na medal, czy też kod, w którym autor wpadł w najbardziej typowe pułapki.
Zła konfiguracja? Taki też był mój pierwszy strzał. Szukałem opcji, które były wyłączone. Znalazłem coś innego: Kotlin po prostu nie ma reguł, do których byłem latami przyzwyczajony. Przyjrzyjmy się konkretnym liczbom.
Jak te liczby przekładają się na konkrety? W „error handling” są reguły typu:
- nigdy nie wolno łapać NullPointerException
- jak wyjątek się łapie, nie powinno się go ignorować, wypada chociaż zalogować
- wyjątek jest tworzony, ale nigdy nie rzucony
Żaden z tych podstawowych, ale też nierzadko spotykanych problemów, nie jest wykrywany w Kotlinie.
Moim osobistym zdaniem Kotlin jest w Sonarze „językiem drugiej kategorii”. Uważam tak nie tylko na podstawie powyższych liczb, ale też przeczytaniu wypowiedzi twórcy Sonara z roku 2020, którzy przyznał, że uruchomienie reguł znanych z Javy w Kotlinie wymaga dużo pracy, a ze względu na rozmiar zespołu mają inne priorytety. Nie mam więc nadziei, że będzie lepiej w przyszłości.
Koszt Sonara to nie tylko pieniądze
Jeśli firma ma opłaconą licencję Sonara, uruchamiać go dla Kotlina czy nie? Niby reguł jest mało, ale zawsze coś. Według mnie – nie, nie uruchamiać.
W moim przypadku wywołanie Sonara w integracji z Gradle’em zajmowało w dużym projekcie 2 minuty. Mierząc po wprowadzeniu optymalizacji związanej z cache’owaniem pewnych danych, bo wcześniej jeszcze paręnaście sekund więcej. W przypadku moich pipeline’ów 2 minuty mniej czy więcej robi sporą różnicę.
W mniejszych projektach ten czas nie jest straszny, ale wciąż znaczący. 7 minut i parę sekund zajmuje cały job, tak end-to-end, czyli kompilacja i testy włącznie z transferem różnych cache’y i artefaktów GitLaba, rozgrzewaniem daemona Gradle’a itp. Z tego 30 sekund to czekanie na Sonara. Moim zdaniem sporo.
Wsparcie techniczne
Integracja Sonara z Gradle’em nie jest bardzo trudna, ale jest niewygodna. Niektóre ścieżki trzeba przekazywać w system properties do wywołania Gradle’a, zamiast jak w normalnym pluginie skonfigurować gdzieś wewnątrz projektu (być może dla części opcji jest to już poprawione).
Reakcja na zgłaszane problemy jest powolna: u mnie Sonar przez rok wypluwał błąd, przy każdym uruchomieniu, przy każdym projekcie. Pojawiały się nowe wersje, nic się nie zmieniało. Dopiero gdy poprosiłem o poprawę lub schowanie tego komunikatu, twórcy zaczęli coś robić w tym kierunku. Wydaje mi się, że duży projekt ciągnie mała grupa osób nadmiernie obciążonych pracą.
Przedziwny jest sposób uzyskiwania wsparcia (tak właściwie, „przedziwny” to najbardziej dyplomatyczne określenie, jakie pasuje do stanu rzeczy). Trzeba pisać na publicznym forum, nie ma niczego w rodzaju ticketów, przydzielonej osoby kontaktowej. W pewnym momencie zostałem poinstruowany, by logi z firmowego CI wrzucić jako publicznie dostępny dla całego Internetu załącznik. Nie ma żadnego innego kanału dzielenia się poufnymi danymi.
Co do Kotlina zamiast Sonara
Odpowiedź podał cytowany wyżej twórca Sonara: Detekt. Coś jak nowoczesny FindBugs/SpotBugs, ale tylko do Kotlina. Darmowy, ale całkiem dobrze zintegrowany z innymi narzędziami. Jest nawet opcja wyświetlania problemów znalezionych przez Detekt w UI Sonara, w ramach jednego raportu.
