Jak zrobić dobre code review
Jeśli używasz code review, to wiesz jakie plusy Ci ono daje. Rozpoczynając od poszerzania wiedzy w zespole po prawdopodobnie prawidłowe działanie aplikacji. Jednak aby code review było dobre oraz przyjemne dla autora i osoby je wykonującej a nie tylko przykrym obowiązkiem, należy wykonać parę rzeczy.
Po pierwsze przypisanie osób. Jeśli to możliwe, nie dawaj kodu do inspekcji ciągle do jednej osoby ale do różnych. Tak samo kod seniora może przeglądać junior a nie inny senior. Od każdego można się czegoś nauczyć i
każdy zwraca uwagę na inne aspekty oraz ma inny punkt widzenia.
Autor zmian w code review
Autorze osoba, która robi Tobie code review najprawdopodobniej będzie chciała Ci je wykonać najlepiej jak jest w stanie ale zawsze może mieć zły dzień,
Małe zmiany
Jeśli to możliwe do przeglądu dawaj małe zmiany. Gdy w oddanym kodzie jest kilkadziesiąt zmian, jeden duży commit dla dwutygodniowego taska to trudno aby code review było wykonane dobrze i żeby wszystko można było w nim zobaczyć. Może to się wydawać trudne, żeby pokazać komuś nie skończoną pracę. Jednak można taska podzielić na mniejsze części, np napisanie testu, wystawienie pustej końcówki restowej, dto, itd. Dzięki temu podejściu możesz zyskać to, że ewentualna duża zmiana zostanie wprowadzona szybko. Oszczędność Twojego czasu może tu być duża.
Rozmowa
Gdy Twoje zmiany są duże, wprowadzasz nową bibliotekę, zastosowałeś ciekawe rozwiązanie i możesz o nich opowiedzieć – zrób to. Po pierwsze dla osoby która robi review łatwiej będzie zrozumieć co zrobiłeś. Po drugie jeśli potrafisz wytłumaczyć swój kod, to powinno być dobrze. Jednak gdy masz z tym problem, to musisz coś w swojej pracy poprawić.
Działający kod
Gdy Twój kod trafia do finalnego przeglądu, projekt musi się kompilować a testy przechodzić.
Osoba przeprowadzająca code review
Pamiętaj autor kodu, spędził nad nim jakiś czas. Wiele rzeczy jest
przemyślanych i zrobionych raczej najlepiej jak autor mógł. Co nie
zmienia faktu, że czasem mógł coś pominąć lub zrobić inaczej/lepiej.
Komentarze
Komentarze są najważniejszą częścią code review. Tutaj można popełnić wiele błędów ale też sprawić że przegląd będzie bardzo pozytywnie odebrany.
- Po pierwsze niech Twoje komentarze będą w formie pytania, sugestii a nie rozkazu. Dobrym przykładem może być “Co myślisz o zmianie nazwy…”, “Dlaczego użyłeś…”. Ich odbiór w porównaniu do np “Zmień to” jest całkiem inny. Kolejnym plusem tego podejścia jest, to że otwierają pole do dyskusji a autor może się zastanowić.
- Komentarze muszą być jasne, konstruktywne i wnosić jakąś wartość. “Zmień to”, “Każdy zrobiłby to lepiej” to właściwie strata czasu. Lepiej powiedz konkretnie, że np możesz użyć wzorca x lub biblioteka y ma tą metodę.
Czas
Do wykonania inspekcji kodu czasem potrzeba chwili a innym razem dużo więcej czasu. Z tego powodu lepiej kod review przeprowadzać na spokojnie. W moim przypadku dobrze sprawdzało się robienie go rano albo po obiedzie. O tych porach nie miałem jeszcze odpowiedniego flow do pracy, więc spokojnie mogłem skupić się na inspekcji kodu.
Logika biznesowa
Nie każdy zna kod całej aplikacji. Czasem zdarza się, że zmiana narusza jakieś założenia biznesowe. Dobrze wtedy zapytać autora czy o tym wiedział i czy działanie aplikacji jest poprawne.
Poprawne użycie biblioteki, języka
Czasem ktoś nie zna zbyt dobrze biblioteki, frameworka, częstych idiomów. W takich przypadkach podczas code review można pokazać prawidłowe użycie. Dobrym przykładem może być zastąpienie
String value =map.get("key");
if(value == null) value = "DEFAULT";
, konstrukcją która istnieje w javie 8
String value = map.getOrDefault("key","DEFAULT")
Clean code
Podczas code review powinieneś sprawdzić czy kod jest czytelny. Nazwy są odpowiednie i zrozumiałe. Klasy, metody nie są zbyt długie i skomplikowane. Czy nie zostają śmieci – niepotrzebne komentarze, nieużywane elementy.
Bonus tip – Pochwała
Pochwała – na pierwszy rzut oka drobna rzecz ale zmienia bardzo code review. Spróbuj w przeglądanym kodzie znaleźć coś fajnego i pochwalić, za to autora. Np “Super, że nie napisałes StringUtilsa a wykorzystałeś z commonsów”.
Jeśli code review w Twoim zespole nie jest idealne spróbuj zastosować się do tych rad. Może okaże się, że dużo dzięki temu zyskasz.