Code review, czyli inspekcja kodu – co to jest i jak poprawia stabilność aplikacji?

Code review, czyli inspekcja kodu – co to jest i jak poprawia stabilność aplikacji?

Masz do wyboru dwie aplikacje o podobnym przeznaczeniu. Jedna z nich się zawiesza, a jej widoki wolno się ładują. Druga działa bez zarzutu. Na którą się zdecydujesz?

Nie trzeba mieć specjalistycznej wiedzy, by zrozumieć, że pierwszy produkt raczej nie zrobi kariery. Użytkownicy potrzebują stabilnej aplikacji, która jest często aktualizowana i pozwala sprawnie realizować zadania.

Aby ją stworzyć, niezbędny jest wysokiej jakości kod. To dzięki niemu aplikacja jest funkcjonalna i może zapewniać użytkownikom lepsze doświadczenia.

W osiągnięciu tego celu pomaga code review.

Co to jest code review?

Code review to inaczej przegląd lub inspekcja kodu. Polega na analizie kodu napisanego przez innego programistę po to, by wykryć potencjalne błędy. Po zbadaniu kodu źródłowego recenzent przekazuje autorowi swoje uwagi na jego temat – zarówno negatywne, jak i pozytywne.

Jakie elementy są sprawdzane? To zależy od zespołu oraz od wymagań projektowych. Zazwyczaj staramy się jednak znaleźć odpowiedzi na kilka podstawowych kwestii:

  • Czy kod jest zgodny ze standardami przyjętymi przez zespół?
  • Czy wzięto pod uwagę wszystkie przypadki (szczególnie te skrajne, czyli edge cases)?
  • Czy nie występują typowe błędy związane z zastosowanym językiem programowania albo błędy logiczne?
  • Czy wprowadzone zmiany zapewniają maksymalną wydajność i stabilność aplikacji?
  • Czy kod jest przejrzysty i zrozumiały?

Warto wiedzieć Przeglądając różne artykuły, możesz trafić również na termin peer review. Jest to jakościowa metoda oceny dokonań naukowych. W przypadku projektów, które polegają na tworzeniu oprogramowania to określenie – podobnie jak code review –  oznacza przeglądanie kodu w celu znalezienia błędów. Można więc używać tych nazw wymiennie.

Dlaczego code review jest ważne?

Przegląd kodu stanowi podstawę procesu ciągłego doskonalenia i przynosi wiele korzyści, takich jak:

  • Poprawa jakości kodu – code review pozwala zadbać o stabilne działanie aplikacji i zwiększa szanse na to, że produkt zyska aprobatę użytkowników.
  • Wcześniejsze wykrywanie błędów – wiele błędów da się zauważyć i wyeliminować jeszcze przed testami oprogramowania, co pozwala zaoszczędzić czas i pieniądze.
  • Większe bezpieczeństwo – inspekcja kodu zwiększa prawdopodobieństwo znalezienia krytycznych błędów, co zwiększa bezpieczeństwo kolejnego wydania aplikacji.
  • Zachowanie zgodności, czyli wypracowanego przez zespół standardu kodowania.
  • Większe poczucie odpowiedzialności za projekt – każdy w zespole ma wpływ nie tylko na wygląd własnego kodu, ale też kodu innego specjalisty.
  • Transfer wiedzy – w ten sposób programiści wymieniają się nowymi technikami i narzędziami. Uczą się, jak pisać lepszy kod i szukać alternatywnych rozwiązań oraz lepiej rozumieją problemy biznesowe.
  • Szybkie zapoznanie się z bazą kodu – przeglądy kodu pomagają nowym członkom zespołu wdrożyć się w projekt.
  • Zapobieganie przestojom w projekcie – cały zespół jest zaznajomiony z kodem i wie, jakie zadania są aktualnie realizowane. Dlatego nieobecność jednej osoby nie powoduje przestojów w pracy.

Nikt nie chce być jedyną osobą, z którą można się kontaktować w sprawie danego fragmentu kodu. Podobnie nikt nie ma ochoty zagłębiać się w krytyczny fragment kodu, którego nie zna (zwłaszcza w przypadku awarii na produkcji). Na szczęście przeglądy kodu umożliwiają nieustanną wymianę wiedzy w zespole. Dlatego gdy jeden programista idzie na urlop, może spać spokojnie, bo wie, że zastąpi go ktoś, kto ma wiedzę o projekcie.

Inspekcja kodu pozwala zmniejszyć wydatki

Dlaczego im szybciej wykrywamy błędy, tym lepiej? Według IBM ma to wpływ na obniżenie kosztów. Najniższy (podstawowy) koszt występuje w fazie projektowania. Później jest zwielokrotniony na różnych etapach cyklu wytwarzania oprogramowania. Odnotowujemy wtedy:

  • 100-krotny koszt w fazie konserwacji,
  • 15-krotny koszt w fazie testów,
  • 6,5-krotny koszt w fazie wdrożenia.

Jakie konsekwencje wiążą się z późnym wykryciem błędów w aplikacji?

  1. Użytkownicy będą ją odinstalowywać lub po prostu przestaną z niej korzystać.
  2. Opóźni się cykl wydawniczy aplikacji.
  3. Naprawa błędu będzie większym (i kosztownym) wyzwaniem. Często trudno znaleźć przyczynę błędów zauważonych po długim czasie od momentu, gdy pojawiły się po raz pierwszy.

Podsumowując, niska jakość kodu aplikacji wpływa na wysokość kosztów, jakie trzeba przeznaczyć na jej rozwój.

To wszystko nie oznacza, że code review nie ma wad. Programiści muszą poświęcić na inspekcję swój czas, a to kosztuje. Wydłuża się też proces realizacji poszczególnych zadań. Trzeba jednak pamiętać, że eliminacja błędów na wczesnym etapie procentuje w dłuższej perspektywie. Późniejsze zmiany stanowią większe obciążenie dla budżetu. Code review pozwala ich uniknąć, dlatego jest ważnym elementem procesu rozwoju aplikacji.

Code review a testy jednostkowe

Zdarza się, że niektórzy mylą testy jednostkowe z code review. Różnice pomiędzy nimi są dość znaczące i warto o nich pamiętać.

Testy jednostkowe polegają na weryfikacji małego fragmentu kodu zwanego jednostką. Celem jest sprawdzenie, czy każda jednostka działa zgodnie z oczekiwaniami. Testy te są przeprowadzane w fazie pisania kodu aplikacji. Mogą być uruchamiane automatycznie.

Testy jednostkowe

  • Pozwalają znaleźć głęboko zagnieżdżone i skomplikowane błędy szybciej niż recenzent, ponieważ opierają się wyłącznie na logicznych zależnościach w małych fragmentach kodu.
  • Dobrze wykonane mogą służyć jako dokumentacja dla innych programistów. Dzięki analizie testu deweloperzy dowiadują się, co powinien robić dany fragment kodu.
  • Zmuszają autora do krytycznego myślenia o swoim kodzie, gdy pisze test dla swojej funkcji. Próbuje wtedy wymyślić testy, które wezmą pod uwagę wszystkie skrajne przypadki – również te, które zawierają błędy.

Przykład Piszesz funkcję, która odejmuje od siebie dwie liczby. Żeby ją przetestować, zastosujesz litery lub znaki zamiast liczb. W ten sposób sprawdzisz, czy otrzymany rezultat jest zgodny z Twoimi zamierzeniami.

Code review

  • Na kod patrzy nie tylko jego autor, ale również recenzenci. To pozwala wykryć błędy na wcześniejszym etapie. Wpływa także na poprawę jakości kodu i umożliwia transfer wiedzy w zespole.
  • Dzięki code review sprawdzasz, czy nowy kod jest spójny z przyjętymi standardami i czy do jego napisania wykorzystano najlepsze znane rozwiązania.
  • Pozwala sprawdzić, czy testy jednostkowe zostały napisane poprawnie.

Żadne z tych rozwiązań nie zastępuje drugiego. Można jedynie zdecydować, które z nich ma większy priorytet (i np. wykorzystywać testy jednostkowe tylko w przypadku krytycznych elementów aplikacji). Mechanizmy te nie powinny się też wzajemnie wykluczać. Jeśli chcesz zadbać o wysoki standard projektu, powinieneś zastosować oba te rozwiązania.

Sposoby przeprowadzania code review

Inspekcję kodu można przeprowadzać na różne sposoby. Poniżej przedstawiam przykładowe metody.

Recenzja wspomagana narzędziami

W Holdapp najczęściej wybieramy asynchroniczny rodzaj code review, czyli wspomagany narzędziami pozwalającymi przeglądać kod (np. GitLab). Takie rozwiązania ułatwiają pracę deweloperom, ponieważ:

  • automatycznie gromadzą zmienione pliki i wyświetlają różnice,
  • umożliwiają wymianę wiadomości między autorem a recenzentami,
  • pozwalają ocenić skuteczność procesu za pomocą metryk,
  • zwiększają automatyzację procesu przeglądu kodu.

Programowanie w parach

W przypadku bardziej skomplikowanych problemów dobrze sprawdza się programowanie w parach (pair programming). Zaangażowanych jest w to dwóch programistów, którzy ze sobą współpracują. Jeden z nich pisze kod, a drugi w tym samym czasie go przegląda. Mają wspólny cel, czyli znalezienie najskuteczniejszego rozwiązania problemu. Ten sposób jest dość czasochłonny, dlatego stosuje się go w przypadku trudnych zadań.

Recenzowanie „przez ramię”

To synchroniczny rodzaj code review. Tutaj również współpracuje ze sobą dwóch programistów – autor i recenzent – którzy patrzą na wspólny ekran (może się to odbywać zdalnie). Autor uzasadnia, dlaczego zdecydował się na wybrane rozwiązania, a recenzent zadaje pytania i przedstawia swoje sugestie. Poprawki można wprowadzać w trakcie recenzowania lub później. Ta metoda jest szybsza niż praca w parach, ale recenzent nie ma wtedy tak dużej wiedzy na temat kodu.

Wymiana wiadomości e-mail

To rzadko stosowana metoda, z której opłaca się korzystać jedynie w przypadku drobnych problemów i małych fragmentów kodu. Ten sposób recenzowania opiera się na wymianie wiadomości e-mail. Programista wysyła tą drogą informacje o zmianach do całego zespołu deweloperskiego. Zwykle odbywa się to za pośrednictwem systemów kontroli wersji, które automatyzują powiadomienia. Taki e-mail inicjuje rozmowę na temat kodu. Podczas niej członkowie zespołu zalecają dalsze zmiany, wskazują błędy lub proszą o wyjaśnienia.

Kiedy ma miejsce code review i jak przebiega?

W Holdapp code review przeprowadzamy wtedy, gdy programista skończy pisać kod, ale zanim połączy zmiany z głównym kodem aplikacji.

Najpierw programista tworzy kod na nowej gałęzi, czyli tzw. branchu. Jest to osobne miejsce w repozytorium, które pozwala bezpiecznie pracować nad zmianami – bez obawy, że wpłynie to na główną bazę kodu.

Po zakończeniu pracy deweloper otwiera pull request, czyli żądanie scalenia z główną bazą. W ten sposób informuje, że czeka na przegląd kodu. Dopóki nie zostanie on zaakceptowany, zmiany w kodzie nie mają wpływu na inne zadania. Dzięki temu recenzenci mogą poświęcić na code review tyle czasu, ile potrzebują.

Później proces ten przebiega inaczej w zależności od wielkości projektu.

Przypadek nr 1: Małe projekty, które rozwija jeden programista

Recenzentami są osoby spoza projektu. Najczęściej są to programiści, którzy mają czas wolny, np. po zakończeniu pracy nad swoim zadaniem. Dzięki dużej różnorodności recenzentów są duże szanse na wprowadzenie w życie wielu dobrych pomysłów, które usprawnią kod.

Niestety tacy recenzenci mają często minimalną wiedzę na temat projektu, założeń biznesowych czy wymagań API. Z tego powodu nie zawsze mogą wykryć wszystkie błędy.

Szukanie recenzenta odbywa się na dwa sposoby. W pierwszym przypadku chętni recenzenci sami przystępują do przeglądu kodu, co jest najczęstszą praktyką. W drugim przypadku – zwykle po upływie jednego dnia bez recenzji – programista sam zaczyna pisać do potencjalnych recenzentów z prośbą o przegląd kodu. Wtedy zawsze znajdzie się ktoś na kogo można liczyć.

Przypadek nr 2: Większe projekty, nad którymi pracuje dwóch lub więcej programistów

Recenzentami są programiści bezpośrednio zaangażowani w projekt. Przegląd kodu przebiega zwykle szybciej, bo takie osoby mają dużą wiedzę na temat projektu, założeń biznesowych i wymagań API. Dzięki temu większość błędów powinna zostać znaleziona.

Oznacza to też jednak, że wymiana wiedzy odbywa się w niewielkim gronie. To sprawia, że zaproponowane rozwiązania mogą się okazać mniej kreatywne.

W obu przypadkach liczba recenzji i forma code review zależne są od standardów, jakimi kieruje się zespół programistyczny oraz od wymagań projektowych.

W zespołach w Holdapp wszystkie zmiany w kodzie są poddawane inspekcji. Nawet jeżeli edytowano tylko jedną linijkę kodu, sprawdzamy ją przed dodaniem do głównej bazy.

Zabezpieczenie przed błędami

Każdy zespół chce, żeby jego aplikacja była jak najwyższej jakości. W rzeczywistości mamy jednak do czynienia z ograniczeniami alokacji zasobów, takich jak czas, budżet czy możliwości inżynieryjne. Dodatkowo trzeba brać pod uwagę czynnik ludzki i związane z tym ryzyko błędów. Te wszystkie elementy wpływają na jakość aplikacji.

Przegląd kodu nie gwarantuje, że 100% błędów zostanie wyeliminowanych, ale znacząco minimalizuje prawdopodobieństwo ich wystąpienia. Niezbędna jest tutaj systematyczność, a także dobrze zaprojektowany i przemyślany proces. Muszą go przestrzegać wszyscy członkowie zespołu. Dzięki temu szanse na to, że Twoja aplikacja będzie działać bez zarzutu znacznie wzrosną.

Wojtek

Wojtek Byczkowski

iOS Developer

Wycena projektu

Opowiedz nam o swoim projekcie i napisz, jak możemy Ci pomóc.

Dlaczego warto rozwijać z nami projekty?

Logo Mobile Trends Awards

Mobile Trends Awards 2021

Wygrana w kategorii
ŻYCIE CODZIENNE

Nagroda Legalnych Bukmacherów

Nagroda Legalnych Bukmacherów 2019

Najlepsza aplikacja mobilna

Mobile Trends Awards logo

Mobile Trends Awards 2023

Wygrana w kategorii
MCOMMERCE ROZWÓJ

23

opinie klientów

Clutch logo