Home

Lepsze Code Review: Linter

Poświęciłem dużo czasu na analizowaniu praktyk code review w różnych firmach. Postanowiłem napisać mini-cykl o tym jak uczynić ten proces szybszym, łatwiejszym i bardziej efektywnym.

Na pierwszy ogień postanowiłem wziąć Lintery i formatery kodu. Po co są one i jakie problemy rozwiązują?

Jak wyeliminować głupoty?

W code review recenzent kodu sprawdza jakość przede wszystkim wytykając zauważone błędy. Najbardziej wartościowe są te, które pomagają wyeliminować potencjalne bugi lub poprawić architekturę kodu – te jednak są trudniejsze to wykrycia. Najłatwiej znaleźć w czyimś kodzie głupoty – a to brak średnika, a to złe wcięcie, a to kolejność metod w klasie – te na szczęście nie są dla kodu niebezpieczne, jak już to wpływają na czytelność. Czasami z „głupot” popełniamy jednak większe błędy – a to zapomnimy zmienić fdescribe czy xdescribe w testach (wykluczanie testów), użyjemy indeksu tablicy w mapowaniu komponentów Reactowych czy zagnieżdżamy wielokrotne instrukcje warunkowe.

Wszystkie te błędy łączy jedna cecha – mogą zostać wykryte poprzez statyczną analizę kodu, a często nawet naprawione automatycznie.

A więc jeżeli zespół zgadza się, że pewna praktyka nie jest dozwolona w projekcie – to chyba nie powinniśmy za każdym razem tracić czasu gdy zostanie ona zastosowana.

Czym jest Linter?

Linter to narzędzie, które obserwuje nasz kod i analizuje go pod kątem reguł, które w nim zastosujemy. W świecie javascriptowym obecnie najpopularniejszy jest ESLint oraz TSLint – ten jednak powoli jest porzucany na rzecz tego pierwszego.

Popularną praktyką jest użycie jednego z presetów stworzonych przez społeczność, np Airbnb czy Google, jednak większość z Was na pewno doinstaluje do Lintera swoje własne reguły (albo stworzy je od zera).

Większość edytorów czy IDE domyślnie (lub poprzez pluginy) integruje się z Linterami i potrafi w czasie rzeczywistym pokazywać błędy w kodzie (podkreślając błędny kod na czerwono czy żółto – zależnie od tego czy dana reguła jest ustawiona jako error czy warning).

Czym jest formater kodu?

Formater kodu jest poniekąd podobnym narzędziem do Lintera, jednak jego zadanie jest skupione tylko na stylu, gdzie Linter ocenia kod pod kątem jakości i określonych praktyk.

Popularnym od jakiegoś czasu formaterem w świecie Javascriptu jest Prettier, który posiada coraz więcej możliwości w zakresie rozpoznawanych formatów.

Najważniejsze zadania, które przeprowadza taki formater to automatyczne ustawianie wcięć, długości lini, cudzysłowów (lub apostrofów) i pomniejszych cech stylistycznych.

Popularne edytory integrują się z Prettierem i potrafią formatować kod z jego pomocą.

Warto wspomnieć, że Lintery także potrafią analizować wcięcia i zmiany stylistyczne, jednak na podstawie obecnych możliwość ESLinta i Prettiera, polecam używać obu – jednego do jakości a drugiego do formatu.

Jak Linter i formater poprawia code review?

Po tym przydługim wstępie czas przejść do sedna. Raczej każdy rozumie jak wygodne są te narzędzia i jak poprawiają jakość kodu.

Zanim jednak dostrzeżemy poniższe zalety, upewnijmy się że nasz projekt jest skonfigurowany by korzystać z tych narzędzi automatycznie.

Sam posiadam następujące rozwiązanie we wszystkich swoich projektach:

  1. Na hooku pre-commit uruchamiam Prettiera dla wszystkich zmodyfikowanych plików (staged). Formatuje on automatycznie styl, a ja nie muszę się niczym przejmować.
  2. Na hooku pre-push uruchamian ESLint dla zmodyfikowanych plików (staged). Jeśli Linter nie znajdzie błędów uruchamiam testy, a potem następuje push. Jeśli ESLint znajdzie błędy, proces zostaje przerwany, a ja muszę poprawić błędy.

W jaki sposób Linter i formater poprawiają proces code review?

Eliminuje wytykanie błahych błędów

Czas poświęcony na zgłaszanie, a następnie poprawianie błędów związanych ze stylem nie powinien być marnowany.

Dzięki automatycznemu formatowaniu nigdy nie następuje sytuacja, że zgłaszane jest złe wcięcie czy długość linii.

Dzięki sprawdzaniu jakości kodu, błędy uzgodnione w regułach nie zostaną wysłane do repozytorium.

Odciąża zespół psychicznie

Code review bywa stresujące – im więcej zgłoszonych błędów, tym statystycznie więcej konfliktów może pojawić się w związku z określoną sytuacją. Wiele sytuacji jest subiektywnych, więc różnie mogą być rozpatrywane przez zespół.

Reguły często posiadają konfiguracje, które określają zarówno stopień błędu (czy warningu) jak i określony kontekst. Przykładowo Linter może nie zezwalać na class components w React, chyba że używamy w nim this.

Im więcej reguł zostanie przeniesionych na Linter, tym mniej dyskusji będzie mieć miejsce podczas każdego code review. A to nie tylko zysk w czasie, ale też mniej konfliktów.

Poprawia każdy kolejny proces oraz pracę innych zespołów

Wspomniane konflikty traktowałbym precedensowo. Jeżeli zespół w końcu ustali wersję, powinien dodać nową regułę do konfiguracji. Dzięki temu zespół (projekt) będzie budował coraz większy zestaw dobrych praktyk, a te mogą później zostać zastosowane w innych projektach albo nawet jako standaryzacja w całej firmie.

Podsumowanie

Poprzez zastosowanie Lintera i formatera kodu (oraz innych narzędzi do statycznej analizy, jak Typescript) staram się przerzucić z programisty jak najwięcej myślenia, aby mógł skupić się na rozwiązywaniu prawdziwych problemów, zamiast skupiać się non stop na różnych pułapkach w implementacji.

Szczególnie Javascript często jest szkalowany jako język niezrozumiały i niekonsekwentny – Linter idealnie nadaje się do wychwytywania złych praktyk na które JS pozwala i na bieżąco informuje o tym programistę.

Finalnie do code review leci kod poprawnie sformatowany, otestowany (mam nadzieję) i po wstępnym filtrze jakościowym.

Narzędzia z którymi warto się zapoznać:

  • ESLint – popularny Linter Javascript (i ostatnio Typescript)
  • TSLint – Linter Typescript
  • Prettier – formater kodu
  • Husky – narzędzie do obsługi hooków gita.
  • Lint-staged – narzędzie do odpalania Linterów tylko na zmodyfikowanych plikach
  • Awesome ESLint – list zasobów związanych z ESLintem