Code review jako sposób na zapewnienie jakości produktu
Podczas tworzenia aplikacji należy odpowiednio zadbać o jakość pisanego kodu źródłowego. Zawsze pomagają nam w tym dodatkowe narzędzia, takie jak linter, formatter, editorconfig itp. Niestety narzędzia te nie dysponują tak silnym backendem, jakim jest ludzki mózg. Z tego też powodu najskuteczniejszym narzędziem do dbania o jakość tworzonego kodu jest code review.
Co takiego?
Code review. Jest to praktyka zapewniania jakości tworzonego produktu. Polega na tym, że programista (jeden lub kilku) sprawdza kod napisany przez innego programistę i stara się wyszukać w nim błędy.
Jakich błędów szukać w trakcie code review?
Jest to pytanie, na które w Ermlab szukaliśmy odpowiedzi już od pewnego czasu. Wbrew pozorom stworzenie zwięzłej listy najistotniejszych uchybień nie jest prostym zadaniem.
Utworzyliśmy listę, która aktualnie służy nam jako procedura code review. Cały czas próbujemy też ją udoskonalać. Gdy pisałem ten wpis, wyglądała ona mniej więcej tak:
Sprawdzić:
- czy są komentarze do klas i metod oraz zweryfikować, czy mają sens,
- czy są typehinty,
- czy spełnione są reguły formatowania kodu (pylint, autopep8, mypy),
- czy spełnione są zasady SOLID,
- czy są testy,
- czy nie jest naruszone bezpieczeństwo aplikacji,
- czy nie ma przestarzałych/nieużywanych metod,
- czy jest obsługa błędów i czy nie jest wyłapywane BaseException/Exception,
- czy nie ma magic numbers (stosujemy stałe bądź enum),
- czy poziom dostępu do metod jest prawidłowy,
- nazewnictwo funkcji i zmiennych,
- czytelność/zrozumiałość kodu:
- nie więcej niż 40 linii kodu w metodzie,
- nie więcej niż 3 zagnieżdżenia w metodzie (liczymy with, if, for, try).
Czy ta lista jest kompletna?
Jestem pewien, że nie. Prawdopodobnie zauważyłeś, że pojawiają się tam określenia związane z językiem programowania Python. Może się okazać, że do prac na projektem w innej technologi wymagane będzie zmodyfikowanie tej listy — przecież w językach z silnym typowaniem nie będzie type hintów. Mam też świadomość tego, że mogliśmy zwyczajnie coś pominąć podczas tworzenia tego zbioru. Jeśli tak jest, to ucieszy nas komentarz pod wpisem z sugestią, co możemy dodać 🙂
Kiedy robić code review?
Najszybciej jak się da. Jeżeli zmiana jest bardzo prosta, to można poprosić kogoś, aby spojrzał na kod jeszcze przed wrzuceniem go do systemu kontroli wersji. W Ermlab najczęściej stosujemy praktykę przeglądu kodu, gdy funkcjonalność jest przygotowana do scalenia z kodem znajdującym się na głównej gałęzi projektu. Porównujemy zatem różnice pomiędzy dwoma wersjami i oznaczamy linie kodu, które wymagają poprawy.
Czy istnieją narzędzia, które usprawnią ten proces?
Oczywiście! My upodobaliśmy sobie narzędzie merge requests w Gitlab (lub pull requests w Github). Pozwala ono na podgląd zmian pomiędzy dwoma wersjami kodu oraz pozostawienie komentarza przy konkretnej linii. Programista odpowiedzialny za przeprowadzenie code review przypisuje siebie jako osobę odpowiedzialną za konkretny merge request, dzięki czemu wiadomo, kto dany kod sprawdził. W płatnych planach Gitlab otrzymujemy też dodatkową funkcjonalność approvals, dzięki której programiści mogą oznaczać, że kod według nich spełnia wymogi. Approvals pozwala też na ustawienie minimalnej ilości potwierdzeń do scalenia gałęzi. Jeśli nie zostanie ona osiągnięta, to scalenie nie będzie możliwe.
Narzędzia dostępne w Gitlab nie zawsze jednak pozwalają na dobre code review, zwłaszcza gdy zmian jest dużo. My zazwyczaj posiłkujemy się podglądem całości kodu w IDE.
Istnieją również inne narzędzia, takie jak:
- UpSource
- Collaborator
- Crucible
- Gerrit
- i wiele wiele innych
O innych narzędziach niż Gitlab nie jestem jednak w stanie nic powiedzieć, gdyż nie miałem okazji z nich korzystać.
Podsumujemy? 🙂
Code review jest bardzo ważną częścią prac nad projektem. Powinien zostać też na ten etap zarezerwowany czas (najlepiej dla każdego zadania). Warto spisać zasady, które określą, w jaki sposób przeprowadzamy code review. Dokument ten powinien zawierać także listę wyszukiwanych uchybień oraz być przedstawiony całemu zespołowi programistycznemu.
