Code review jest jednym z kluczowych etapów procesu wytwarzania oprogramowania, a w dodatku ma tak wiele zalet, że w zasadzie można napisać o tym osobny artykuł. Ile razy zamiast analizować kod pod kątem poważnych błędów musieliście przeglądać zmiany w jego formatowaniu? Z doświadczenia wiem, że nie są to jednostkowe sytuacje, dlatego przedstawiam kilka sposobów na rozwiązanie tego problemu. Pomoże w tym SwiftLint – jedno z popularnych narzędzi do analizy kodu.

 

Pierwszym krokiem jest stworzenie jednego zestawu reguł definiujących styl kodu, który będzie uzgodniony przez cały zespół. Zapamiętanie wszystkich reguł NIE wystarczy, aby go rozwiązać. Wszak jesteśmy tylko ludźmi i błędy nam się zdarzają!

Na rynku jest wiele narzędzi zaprojektowanych, aby rozwiązać opisywany problem, z czego jedno zasługuje na szczególne wyróżnienie. SwiftLint – bo o nim mowa, to narzędzie do analizy kodu, które umożliwia tworzenie reguł określających format oraz styl kodu. Narzędzie to wyróżnia się bogatym zestawem reguł, które łatwo dostosować do naszych potrzeb.

 

Instalacja

Instalacja SwiftLint jest dosyć prosta i można ją przeprowadzić na kilka różnych sposobów. W tym artykule w celach demonstracyjnych pokażę, jak to zrobić przy użyciu popularnego narzędzia do zarządzania zależnościami o nazwie Homebrew. Sam na co dzień korzystam z innego narzędzia – CocoaPods, które zapewnia spójność wersji biblioteki na maszynach developerów oraz CI (ang. Continous Integration). Wybór jednak należy do Was. O wszystkich możliwościach instalacji możecie poczytać tutaj.

Aby zainstalować narzędzie, najpierw otwórzcie konsolę i uruchomcie:

 

Działanie

Kiedy SwiftLint zostanie zainstalowany, przejdźcie do katalogu głównego swojego projektu i… już możecie zacząć zabawę z tym niezwykłym narzędziem. Po pierwsze, skorzystajcie z polecenia „help”, aby sprawdzić jakie opcje są do Waszej dyspozycji. Na samym początku, sugeruję wykonanie komendy „rules”, która pokaże całą listę dostępnych reguł. Będziecie mogli przejrzeć, które są domyślnie włączone, a które wymagają aktywowania (ang. opt-in). To pomoże Wam zrozumieć, co podlega ewaluacji przez to narzędzie i jakie akcje są podejmowane w razie złamania reguł. Na potrzebę tego artykułu i demonstracji działania narzędzia, stworzyłem nową aplikację iOS z domyślnego szablonu o nazwie „Lint”.

 

Taki rezultat zobaczycie uruchamiając SwiftLint dla zupełnie nowego projektu Xcode. Zaskakująco dużo komunikatów z ostrzeżeniem, nieprawdaż? I to na jeszcze niemodyfikowanym projekcie! Sprawa nie jest oczywista, ale odpowiedź znajdziemy w konstrukcji SwiftLint – reguły zaimplementowane w narzędziu są tak rygorystyczne, że nawet zupełnie czysty projekt Xcode może ich nie spełniać. Co więcej, jak pewnie zauważyliście taka forma prezentacji ostrzeżeń (ang. warnings) nie jest zbyt przyjazna, a praca na co dzień z takim formatem może być prawdziwą drogą przez mękę. Czas to zmienić!

Należy przejść do konfiguracji swojego projektu Xcode, następnie otworzyć zakładkę „Build Phases” i dodać nową fazę budowania aplikacji „Run Script” stosując poniższy skrypt:

 

Został on skopiowany z dokumentacji SwiftLint i jest to jedna z rekomendowanych metod uruchamiania tego narzędzia. Po dodaniu tej fazy budowania, reguły będą ewaluowane przy każdym zbudowaniu aplikacji. Co więcej, gdy skrypt się wykona, w swoim IDE zobaczycie każde ostrzeżenie oraz błąd tuż przy kodzie, który je wywołał. Jest to bardzo przydatne, ponieważ nie musicie opuszczać swojego środowiska programistycznego i pamiętać, żeby ręcznie uruchamiać sprawdzanie reguł.

 

Na pierwszy rzut oka, nie za dobrze to wygląda. Na szczęście większość z tych ostrzeżeń da się łatwo usunąć kasując niepotrzebne spacje, linie kodu czy komentarze. Po takim szybkim czyszczeniu, znikną niemal wszystkie ostrzeżenia poza jednym – naruszenie kryterium długości linii spowodowane przez metodę didFinishLaunchingWithOptions. Jest to dość częsta sytuacja i bardzo dobry przykład sytuacji, w której nie mamy pełnej kontroli nad kodem, który nie jest zgodny z regułami.

Aby pozbyć się komunikatu o ostrzeżeniu lub błędzie, możemy zastosować przedstawioną poniżej składnię, która składa się z:

  • słowa kluczowego swiftlint
  • komendy „enable” lub „disable”
  • zakresu zasięgu tej komendy – „next”, „previous”, „this” lub braku zakresu co sprawia, że jest ona stosowana do całego pliku poniżej niej

 

Należy jednak pamiętać, że każdy kij ma dwa końce. Metoda ta stanowi ogromną pomoc w kontekście zewnętrznych bibliotek, ale o jej zastosowanie mogą się pokusić leniwi programiści do usuwania niewygodnych ostrzeżeń i błędów. Dlatego tak ważne podczas code review jest weryfikowanie czy wyłączenie danej reguły miało rzeczywiście uzasadniony powód.

 

Konfiguracja

Domyślna konfiguracja reguł sprawdza się dobrze, ale moim zdaniem to narzędzie powinno ułatwiać przestrzegania Waszego własnego Style Guide’a (czyli zestawu konwencji oraz reguł pisania kodu) zamiast go kreować. Na szczęście, w łatwy sposób można dostosowywać reguły SwiftLint dodając do głównego katalogu naszego projektu plik .swiftlint.yml.

Kilka prostych kroków do stworzenia nowej reguły:

  1. Uaktualnij swój Style Guide (to nie powinna być decyzja jednej osoby, ale całego zespołu)
  2. Uaktualnij konfigurację reguł SwiftLint, aby dopasować je do Twojego Style Guide’a jak najbardziej to możliwe
  3. Przetestuj nową regułę w praktyce

Tworzenie swojego własnego Style Guide’a nie jest koniecznością, ale w dłuższej perspektywie przynosi wiele korzyści. Code review będzie przeprowadzane według jasnych wymogów, a sam Style Guide może się świetnie sprawdzić jako część procesu onboardingowego dla nowych developerów w zespole. To z pozoru czasochłonne zadanie – ale rozkładając je w czasie poprzez systematyczne dodawanie kolejnych reguł, nawet nie zauważycie dodatkowego nakładu pracy.

 

To jest przykład konfiguracji pliku .swiftlint.yml według oficjalnej dokumentacji SwiftLint.

Składają się na nią następujące części:

  • Linijka 1: Dezaktywuje reguły domyślnie ustawione jako aktywne
  • Linijka 3: Aktywuje reguły do tej pory ustawione jako nieaktywne (ang. opt-in)
  • Linijka 6: Lista uwzględnionych folderów
  • Linijka 8: Lista wykluczonych folderów
  • Linijka 11: Reguła, która w razie załamania zwraca ostrzeżenie lub błąd
  • Linijka 13: Reguła, która pozwala parametryzować, kiedy w razie jej złamania ma być zwracane ostrzeżenie, a kiedy błąd
  • Linijka 17: Reguła dotycząca nazewnictwa, która pozwala ustalić minimalną i maksymalną długość nazwy, której złamanie wywoła ostrzeżenie lub komunikat o błędzie. Dodatkowo posiada listę pomijanych nazw, które z istotnego powodu nie powinny być objęte tą regułą.

Wprawdzie to tylko szybki przegląd dostępnych konfiguracji reguł, ale dotyczy najczęściej spotykanych przypadków.  Polecam odwiedzić oficjalną stronę z dokumentacją na GitHub – znajdziecie tam dużo bardziej skomplikowane lub rzadsze przykłady, takie jak np. tworzenie dedykowanej reguły przy użyciu wyrażeń regularnych.

Przydatne reguły

Jak już wcześniej wspomniałem, to narzędzie powinno wspierać pracę z Waszym własnym Style Guide’em. Jednakże, niektóre z tych reguł tak bardzo ułatwiają życie, że nie mogłem się powstrzymać i ich Wam nie polecić:

  • Force Try, Force Cast, Force Unwrapping – wykrywa wykrzykniki obok opcjonalnych wartości, które nieodpowiednio obsłużone zatrzymają działanie Waszej aplikacji
  • Line Length – ostrzega, jeśli linijka jest zbyt długa (nigdy więcej scrollowania strony podczas code review!)
  • Todo – nie wiem dlaczego nie jest to podstawowa funkcjonalność Xcode’a, ale dzięki tej regule już nigdy nie umknie wam żadne „TODO”
  • Large Tuple – pomaga unikać przekazywania kilku argumentów zamiast opakowania ich w dedykowany typ
  • File Length – eliminuje “wszystko robiące” klasy z Waszego projektu poprzez zwracanie ostrzeżenia lub błędu, gdy poszczególny plik jest za długi.

Istniejące projekty

Kiedy już uda Wam się dopracować konfigurację SwiftLint zgodnie z wymaganiami Waszego Style Guide’a, czas na zaimplementowanie jej w Waszych projektach. Nie jest to problem w przypadku nowych projektów, no ale co z już istniejącymi? Zazwyczaj sprowadza się to do refactoring’u, który należy poprzedzić napisaniem testów jednostkowych dla metod, na które może on mieć wpływ. Zrobienie tego wszystkiego w jednym czasie może się okazać zupełnie nieopłacalne dla projektu – czyli nieakceptowalne dla biznesu.

Szczerze powiedziawszy, nie ma na to złotego środka. Można to obejść zmieniając komunikaty o błędach na ostrzeżenia. Dzięki temu, projekt nadal będzie się kompilował, a Wy zachowacie informacje, które obszary Waszego kodu nie są zgodne z przyjętymi regułami. Takie podejście niesie za sobą następujące korzyści:

  • Nowe funkcjonalności mogą być implementowane z uwzględnieniem pełnego zestawu reguł
  • Reguły są spójne we wszystkich Waszych projektach
  • Dług technologiczny jest łatwy do zidentyfikowania oraz śledzenia

Wnioski

Zalety:

  • Kod posiadający cechy trudnego w utrzymaniu może zostać usunięty we wczesnym stadium
  • Code review zabiera dużo mniej czasu
  • Badanie zgodności z Waszym Style Guide’m jest obiektywne
  • Ułatwia to utrzymanie projektu
  • Sprawdzanie reguł może być częścią procesu CI
  • Ujednolicenie kodu sprawia, że jest on znacznie czytelniejszy

Wady:

  • Stworzenie jednolitego zestawu reguł dla wielu różnych projektów może w początkowej fazie zabrać sporo czasu
  • Nie każda reguła z Waszego Style Guide’a moze zostać zweryfikowana przez SwiftLint

SwiftLint to potężne, a jednocześnie łatwe w użyciu narzędzie dla developerów Swifta. Może Wam bardzo pomóc w egzekwowaniu reguł oraz konwencji pisania kodu przez Wasz zespół. Mimo, iż stare projekty mogą sprawiać pewne problemy, przy dobrym podejściu możecie je obejść i wprowadzić nową (wyższą) jakość do wszystkich Waszych projektów. I z tego miejsca, gorąco Was zachęcam do przeczytania oficjalnej dokumentacji i wypróbowania pełnych możliwości tego świetnego narzędzia.

 

Oceń ten wpis
(9)
Krzysztof Juchnowicz
Krzysztof Juchnowicz
O autorze

Najnowsze posty autora |
więcej postow tego autora
MakoLab korzysta z plików cookie w celu realizacji usług zgodnie z Polityką prywatności. Możesz określić warunki przechowywania lub dostępu do cookie w Twojej przeglądarce lub konfiguracji usługi.
Obserwuj MakoLab na portalach społecznościowych
Chcesz być na bieżąco z MakoNewsami? Zapisz się na nasz newsletter.