WIADOMOŚCI

Poprawa jakości kodu dzięki SonarQube

Published on:15 / February / 2016

Utrzymanie pewnego poziomu jakości i czytelności kodu ma zasadnicze znaczenie dla udanego rozwoju oprogramowania w dzisiejszym dynamicznym środowisku rozwojowym, w którym wiele zespołów pracuje nad tym samym kodem i wprowadza w nim zmiany. Takie środowisko wymaga przestrzegania pewnych konwencji kodowania, dzięki którym kod jest zrozumiały dla wszystkich uczestników procesu.

Dla nas w firmie Infobip niezmiernie istotne jest, aby produkty, które dostarczamy, spełniały najwyższe normy jakości. Podstawą każdego produktu jest kod źródłowy, co czyni jakość kodu najważniejszym czynnikiem określającym jakość całego produktu.

Aby zachować wysoki poziom kontroli jakości, postanowiliśmy wdrożyć analizę kodu do naszego procesu rozwojowego. Jednak po pewnym czasie takie analizy zaczęły zajmować zbyt dużo czasu, odwracając naszą uwagę od innych ważnych zadań. Analiza kodu obejmuje nie tylko proces analizy twórczej, lecz także wyszukiwanie powtarzających się błędów, sprawdzanie stosowania zasad konwencji itp. Pod uwagę brany był cały proces, więc logicznym rozwiązaniem była automatyzacja jego części.

W naszych centrach rozwoju oprogramowania staramy się automatyzować jak najwięcej zadań manualnych, żeby móc się skupić na innowacji,która decyduje o wyborze naszych rozwiązań przez klientów. Obecnie nasi programiści mogą automatycznie wdrażać usługi, szybko i łatwo pisać publiczne API oraz generować biblioteki klienta w różnych językach programowania. Znalezienie idealnego rozwiązania, pomocnego w częściowej automatyzacji analizy kodu, zajęło nam długi czas. Po przeanalizowaniu różnych narzędzi doszliśmy do wniosku, że SonarQube spełnia wszystkie nasze wymagania.

Informacje o SonarQube

SonarQubeto otwartoźródłowa platforma do analizy jakościowej kodu. Należy ona do narzędzi analizy statycznej kodu, podobnie jak Understand, semmlei in..

Platforma otrzymuje kod źródłowy jako dane wejściowe. Kod ten może zostać wysłany z IDE lub zassany z SCM. Dostępne są wtyczki SonarQube do najbardziej popularnych IDE, które jeszcze bardziej ułatwiają analizę kodu. Na podstawie danych wejściowych platforma zaczyna stosować zdefiniowane zasady i sprawdza, czy zostały one spełnione. W ramach danych wyjściowych analizy platforma przekazuje wiele przydatnych informacji i propozycji poprawek.

Wybraliśmy SonarQube ze względu na liczne i szerokie zasady Java. Obecnie dostępnych jest ponad 700 zasad Java, a ich liczba stale rośnie. Analizujemy głównie kod napisany w języku Java, ale można też łatwo przeprowadzić analizę kodu napisanego w jednym z 20 innych języków programowania.

SonarQube zezwala również na dodawanie wtyczek, można więc napisać własne wtyczki, jeśli konkretny język nie jest obsługiwany lub jeśli potrzebne są własne zasady. Aby dodać własne zasady kodowania, można użyć rozszerzeń XPath lub stworzyć nową wtyczkę przy użyciu Java.

Platforma SonarQube składa się z czterech komponentów: analizatorów, serwera, wtyczek zainstalowanych na serwerze oraz bazy danych.

                                                                                        Architektura SonarQube

Analizatory odpowiadają za przeprowadzenie analizy kodu wiersz po wierszu. Mogą one dostarczyć informacji na temat długu technicznego, zasięgu kodu, złożoności kodu, wykrytych problemów itp. Problemami wykrytymi w kodzie mogą być błędy, potencjalne błędy, kwestie mogące prowadzić do błędów w przyszłości itp. Po przeprowadzeniu analizy jej wyniki można zobaczyć na stronie internetowej hostowanej na serwerze internetowym SonarQube. Serwer internetowy upraszcza konfigurację instancji SonarQube i instalację wtyczek oraz zapewnia intuicyjne omówienie wyników.

Enigneering

                                                                                                Omówienie wyników

W kodzie można znaleźć wiele problemów. Zasady są różne i można je podzielić na 5 grup w zależności od ważności: bloker, krytyczne, istotne, nieistotne i informacyjne. Każdy wykryty błąd lub potencjalny błąd zostanie zatem scharakteryzowany jako problem typu bloker lub problem krytyczny, a niektóre nieistotne problemy, takie jak „Nie należy stosować liczb magicznych” oceniane są jako problemy nieistotne lub informacyjne.

Oto przykład najczęściej łamanych zasad:

Engineering

                                                                          Najczęściej łamane zasady

Świetne w SonarQube jest to, że wszystkie dane są przechowywane w relacyjnej bazie danych, z którą wszyscy programiści są generalnie zaznajomieni. My wybraliśmy bazę danych MySQL. Po pierwsze dlatego, że jesteśmy wielkimi zwolennikami technologii otwartoźródłowych. Jeśli ktoś ma inne preferencje dotyczące baz danych albo ma więcej doświadczenia w pracy z inną bazą danych, może wybrać inną z obsługiwanych baz danych, takich jak: PostgreSQL, Oracle itp.

Konfiguracja SonarQube

Architektura SonarQube zezwala na oddzielenie serwera i bazy danych, a nawet na tworzenie replik bazy danych oraz uruchamianie serwera na kilku maszynach w celu uzyskania lepszej wydajności i skalowalności.

Do celów testowych i do wypróbowania różnych funkcji SonarQube można użyć serwera internetowego z osadzoną bazą danych oraz przeanalizować jeden lub dwa projekty. Jeśli środowisko zostanie prawidłowo skonfigurowane od samego początku, nie będzie trudności z migracją bazy danych i serwera SonarQube z lokalnej maszyny programistycznej na serwer. Pomocny może być w tym Docker i jego kontenery, umożliwiające zawarcie wszystkiego co potrzebne (bibliotek kodów, bibliotek uruchomieniowych i bibliotek systemowych) i łatwe wdrożenie na dowolnej maszynie. SonarQube ma też swój własny oficjalny kontener Dockerz osadzoną wersją H2, więc nie trzeba tracić czasu na tworzenie własnego. Można także skonfigurować zewnętrzną bazę danych potrzebną do poważniejszej pracy z SonarQube.

Zaczęliśmy od jednej dedykowanej wirtualnej maszyny i nie mieliśmy problemów, dopóki liczba projektów nie przekroczyła pewnego poziomu i dopóki nie zaczęliśmy analizować kodu na porządku dziennym. Wtedy jednak zaobserwowaliśmy drastyczny spadek wydajności i wydłużenie czasu analizy. Zaczęliśmy wówczas oddzielać różne warstwy SQ (architektury) na różnych maszynach.

Na początek oddzieliliśmy bazę danych i serwer Sonar. Przyjęliśmy rekomendacje SonarQube, aby być w tej samej sieci.  Do wdrożenia SonarQube stosujemy kontener Docker, co ułatwia instalację na innej maszynie, jeśli potrzebny jest wyższy poziom wydajności.

SonarQube i ciągła integracja

Jak wcześniej wspomnieliśmy, dbamy o automatyzację i staramy się poświęcać mniej wysiłków na to, co można zautomatyzować, przez co zapewniamy sobie więcej czasu na kreatywne zadania. Analiza kodu doskonale wpasowuje się w ideę ciągłej integracji.

Stosujemy i głosimy ciągłą integrację oraz zwinne programowanie. Proces rozwiązania jednego zadania z naszej perspektywy wygląda tak.

Najpierw programista (powiedzmy, Alisa) wyznacza sobie zadanie i rozpoczyna proces. Podczas rozwiązywania zadania Alisa wielokrotnie przeprowadza analizę kodu w IDE i otrzymuje wyniki. Alisa widzi, czy wszystkie wymagania dotyczące jakości kodu zostały spełnione. W odniesieniu do logiki, Alisa musi ją sprawdzić sama. Gdy Alisa ma pewność, że napisany kod spełnia wszystkie wymagania, przesyła nowy kod do repozytorium i prosi Boba, żeby go przeanalizował. Po przesłaniu zmian do repozytorium git webhook uruchamia wersję programu Jenkins. Wersja działa automatycznie, a artefakt z nową funkcją jest dostępny w wewnętrznym repozytorium maven i może łatwo zostać wdrożony do produkcji.

Bob analizuje kod, który napisała Alisa i sprawdza, czy jakość kodu jest na odpowiednim poziomie. Po zinterpretowaniu wyników Bob musi tylko przeprowadzić kreatywną część analizy – analizę logiki. Jeśli wszystko jest w porządku, zadanie zostało zakończone, a nowa funkcja jest gotowa do produkcji.

Engineering

Zarządzanie kodem źródłowym za pomocą serwera CI i SonarQube

W wersji 4.0 wprowadzono tryb analizy przyrostowej. Tryb ten można wykorzystać do sprawdzenia, czy nowe zmiany złamią jakieś ważne zasady kodowania, i może zostać uruchomiony przez programistę, który wprowadził te zmiany. Przed wersją 4.0 programista rozpoczynał analizę całego projektu, nawet jeśli zmienił tylko dwa lub trzy pliki. Nowa funkcja znacząco skraca czas potrzebny na analizę. Poza nowym trybem przyrostowym dostępna jest też analiza całego projektu – analiza wiersz po wierszu, która wysyła wyniki do serwera i przechowuje je w bazie danych – a także tryb podglądu, który przeprowadza pełną analizę, ale bez przechowywania wyników w bazie danych.

Obecnie wykorzystujemy tryb analizy całego projektu z przechowywaniem wyników do wersji nocnych, a tryb podglądu – po każdym przesłaniu.

Daje to możliwość śledzenia kontroli jakości kodu od przesłania do przesłania. Ponadto posiadamy dane historyczne dotyczące jakości kodu, więc możemy obserwować, jak zmieniała się jakość w ciągu projektu.

Podsumowanie

Stosowanie SonarQube usprawnia kontrolę jakości kodu oraz zmniejsza liczbę faktycznych i potencjalnych błędów. Programiści koncentrują się teraz bardziej na samej logice i mogą poświęcić czas na wymagania dotyczące analizy biznesowej oraz znalezienie optymalnego rozwiązania dla danego przypadku. Ponadto po wdrożeniu menedżerowie zaczęli śledzić mierniki, ponieważ uważają, że na podstawie wyników można dowiedzieć się więcej o pracy programistycznej.

Zacytuję Johna F. Woodsa:

„Zawsze koduj tak, jakby facet, który będzie z nim później pracował, był brutalnym psychopatą, który wie, gdzie mieszkasz”.

Na co czekać? Dziś jest doskonały dzień na analizę kodu.

 

By Nevena Menkovic, Software Engineer