code-review-checklist
code-review-checklist

Code Review z użyciem checklisty

Współczesny świat dał nam niesamowitą wiedzę. Jednak niepowodzenia, których można uniknąć, nadal nękają nas w służbie zdrowia, rządzie, prawie, branży finansowej, słowem w prawie każdym obszarze zorganizowanej działalności. Powód jest prosty: ilość i złożoność dzisiejszej wiedzy przekroczyła nasze indywidualne możliwości prawidłowego przekazywania jej ludziom – konsekwentnie, poprawnie i bezpiecznie. Trenujemy dłużej, bardziej się specjalizujemy, korzystamy z ciągle rozwijających się technologii, a mimo to ponosimy porażkę. Atul Gawande w swojej książce “The Checklist Manifesto: How to Get Things Right” przedstawia przekonujący argument, że możemy to zrobić lepiej, używając najprostszej z metod: listy kontrolnej. Przykładem może być prosta chirurgiczna lista kontrolna Światowej Organizacji Zdrowia (WHO). Została ona przyjęta w ponad dwudziestu krajach, jako standard opieki i została ogłoszona „największym wynalazkiem klinicznym od trzydziestu lat” (The Independent).

Chociaż tworzenie oprogramowania nie jest przedsięwzięciem typu śmierć i życie, możemy zastosować te same lekcje, wykorzystując listy kontrolne.

Co to jest Code Review (pol. przegląd kodu)?

Gdy programista w zespole chce opublikować kod, nad którym pracował, musi wykonać pull request – czasami może to być jednak bolesne.

Zanim nowy kod ujrzy światło dzienne (a użytkownicy będą mogli skorzystać z nowej funkcji produktu), inni członkowie zespołu muszą dokonać przeglądu kodu, czyli Code Review. Oznacza ono sprawdzanie błędów, identyfikację ewentualnych problemów (m.in. ze standardami kodowania przyjętymi w organizacji / produkcie / projekcie) i sugerowanie ulepszeń.

Reklama


Po co tworzyć listę kontrolną Code Review?

Ogólnie rzecz biorąc, recenzje kodu są świetne. Radykalnie poprawiają jakość kodu, zwiększają produktywność programistów i zapobiegają przedostawaniu się błędów do użytkowników.

Ale bez dobrego procesu Code Review, może on być bardzo dotkliwy.

Listy kontrolne w procesie Code Review pomagają:

  • zapewnić produktywne przeglądy, 
  • zapobiegać prostym błędom, 
  • weryfikować wykonanie pracy, 
  • zwiększyć wydajność programisty, 
  • zapewnić, że utrzymane są przyjęte standardy jego produkcji.

Jakie elementy powinien mieć Code Review Checklist?

1. “Etykieta” Pull Requesta

Czy Pull Request, na który patrzysz, jest rzeczywiście gotowy do przeglądu? Oto kilka kluczowych zasad, które powinny mieć zastosowanie, aby to ustalić:

  • Częstotliwość – aby ułatwić zarządzanie Pull Requestami, przesyłaj je jak najczęściej. Jeśli zmiany w kodzie obejmują wiele dni pracy, bez uzasadnionego powodu, należy je podzielić na mniejsze fragmenty i przesłać osobny Pull Requesty;
  • Rozmiar Pull Requesta – jeśli jest on zbyt duży, trudno drugiej stronie go zrozumieć. Powinien być podzielony tak bardzo, jak to możliwe;
  • Komentarze – czy Pull Request ma wystarczającą liczbę komentarzy, aby ułatwić przegląd kodu?
  • “Pojedyncza odpowiedzialność” (ang. Single Responsibility Principle) – kod powinien zawsze rozwiązywać tylko jeden problem. 

Jeśli powyższe warunki nie są spełnione, kod powinien być zwrócony do autora celem ulepszenia go lub rozdzielenia na kilka Pull Requestów.

2. Standardy kodowania

Ustaw kilka podstawowych zasad kodowania i upewnij się, że są one przestrzegane. Spójne standardy są niezbędne, aby programiści mogli łatwo zrozumieć kod i pracować wydajnie.

Kilka podstawowych zasad:

  • Czy nazwy zmiennych są rozsądne i konsekwentnie pisane wielkimi literami?
  • Czy w całym kodzie są wystarczająco opisowe komentarze, zgodne z wymaganiami?
  • Czy przestrzegane są preferencje formatowania kodu? Na przykład: tabulatory lub spacje, nawiasy klamrowe w tym samym lub nowym wierszu, szerokość linii?

Aby zaoszczędzić czas, możesz sprawdzić, czy te zasady są przestrzegane za pomocą automatycznego reguł, często już ustawianych w edytorze. 

Ponownie, jeśli te standardy nie są spełnione, przestań sprawdzać kod i zwróć go do autora.

3. Bezpieczeństwo

Ustal standardy bezpieczeństwa dla swojego projektu i sprawdź, czy są one przestrzegane. Reguły do sprawdzenia będą się różnić w zależności od projektu i organizacji, ale niektóre z najlepszych praktyk to:

  • Uruchom swój projekt za pomocą rozwiązań do wykrywania luk w zabezpieczeniach; 
  • Nie koduj na stałe poświadczeń do testowania ani nie dołączaj kluczy tajnych do repozytorium;
  • Nie ujawniaj zbyt wielu informacji w komunikatach o błędach, które mogą dać wskazówkę atakującemu;
  • Upewnij się, że wszystkie zapytania do bazy danych są sparametryzowane;
  • Nie ufaj ślepo danym wejściowym użytkownika lub klienta – Twój klient lub aplikacja internetowa może zostać zmodyfikowana. Na przykład należy sprawdzić parametry adresu URL, które mają dostęp do zasobów.

Jeśli zidentyfikujesz problemy z bezpieczeństwem w procesie Code Review, zatrzymaj się i porozmawiaj z autorem. Może to oznaczać poważniejszy problem w projekcie lub brak szkolenia.

4. Wydajność 

Wydajność jest niemniej ważnym elementem budowania czy zmieniania produktu dla użytkownika. Zauważamy, że dana strona nie jest wystarczająco szybka, że czasami niektóre funkcje nie działają z taką szybkością, jaką oczekujemy.

W czasie procesu Code Review należy zwrócić, jako przeglądający szczególną uwagę na kwestie związane z wydajnością.

  • Czy użytą bibliotekę można zastąpić wydajniejszą?
  • Czy istnieje kod do debugowania lub rejestrowania, który można usunąć?
  • Czy jest używane buforowanie, jeśli ma to zastosowanie?
  • Czy obrazy i zasoby są odpowiednio skompresowane (jest to o tyle istotne, że wielkość przesyłanych plików na decydujące znaczenia dla wydajności)?

Istnieje wiele narzędzi, które mogą pomóc w optymalizacji wydajności projektu. Dobre miejsca do rozpoczęcia to Chrome Lighthouse (zwany także PageSpeed Insights) i DebugBear dla projektów frontendowych.

5. Testowanie 

Testy automatycznie sprawdzają, czy kod robi to, co powinien, czyniąc je kluczową częścią procesu przeglądu kodu.

Po pierwsze, sprawdź, czy testy są obecne i dobrze udokumentowane dla wszystkich typowych funkcji. Jeśli niektóre funkcje nie są objęte testowaniem, należy dobrze udokumentować, dlaczego tak jest.

Po drugie, upewnij się, że testy są dobrze odizolowane, abyś mógł szybko znaleźć problem, jeśli test się nie powiedzie.

Wreszcie, czy testy sprawdzają kod? Często testy dają komunikaty, że tak, ale tak naprawdę nie oceniają zamierzonej funkcji aplikacji.

Zawsze pamiętaj, że nie wszystkie testy są “kuloodporne” i nie należy polegać na nich całkowicie, jak dowodzi następna pozycja listy kontrolnej…

6. Czy faktycznie nowy kod działa? 

Jeśli jesteś w zwinnym zespole, kod powinien być zawsze sprawdzany pod kątem kryteriów akceptacji określonych przez Product Managera, Lidera, Product Ownera. Jeśli kryteria akceptacji (które są częścią User Story, opisu wymagania) nie są spełnione, zapytaj autora o przyczynę.

Innym częstym problemem jest to, że kod działa lokalnie, ale nie na produkcji. Cały przeglądany kod należy wdrożyć w środowisku przejściowym (np. środowisko pre-produkcyjne), które jest spójne ze środowiskiem produkcyjnym. Zapobiega to problemom specyficznym dla środowiska produkcyjnego (np. konfiguracja).

7. Kultura Code Review

Zanim wyślesz opinię o nowym kodzie, sprawdź, czy Twoje komentarze pomogą Twojemu zespołowi ulepszyć go, a nie będą postrzegane jako krytyka.

Code Review to jedne z najczęściej występujących interakcji z resztą zespołu. Poświęć trochę czasu, aby upewnić się, że opinie na temat nowego kodu zostały sformułowane w pozytywny sposób, aby z czasem przyczynić się do pozytywnej, opartej na współpracy kultury Code Review.

Widziałem w moim życiu zawodowym zespoły, które razem przebywały w kuchnii i normalnie ze sobą rozmawiały, jednak w procesie Code Review powstawały dwa obozy. Było to związane z brakiem standardów, ale też ze słabą “kulturą” Code Review. Wytykanie sobie błędów zamiast konstruktywnej, pozytywnej krytyki powodowało, że Product Owner nie miał elementów produktu, które mógłby zaakceptować do wdrożenia. Przeciąganie Code Review powodowało demotywację członków zespołu jak i brak dostarczenia wartości dla użytkownika końcowego, co w oczywisty sposób mogło przełożyć się na KPI, cele, przychody zespołu / organizacji.

8. Ciągle przeglądaj listę kontrolną

Twoja lista kontrolna jest dobra tylko wtedy, gdy jest aktualna. Dlatego ważne jest, aby stale przeglądać listę kontrolną i upewniać się, że spełnia ona Twoje potrzeby.

Twoje (zespołu) potrzeby w zakresie Code Review będą się zmieniać z czasem, gdy dołączą nowi członkowie zespołu lub Twój projekt (deweloperski) będzie miał nowe wymagania. 


       

Jeżeli chcesz poznać więcej wskazówek (hintów) dotyczących Code Review, sięgnij do książki AgileHints.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X