Jak robić dobre code review

dobre code review

Dla nas developerów, code review to chleb powszedni i zarazem nieodłączny element codziennej pracy programistycznej. Często jednak w natłoku obowiązków traktujemy je po macoszemu i chcemy jak najszybciej mieć z głowy. W backlogu czekają przecież inne taski, a kod sam się nie napisze itd. Takie podejście to błąd. Warto zacząć traktować code review poważnie, robić je świadomie i wygospodarować na tę czynność więcej czasu. Dlaczego? Dowiesz się z tego artykułu 🙂

Spis treści

Piszesz mniej niż myślisz

Statystycznie developer pisze kod jedynie przez około 10-20% czasu pracy każdego dnia. Trudno się z tym nie zgodzić. Realnie patrząc, więcej zajmuje nam myślenie nad rozwiązywaniem problemów, czytanie i analizowanie kodu oraz różnego rodzaju spotkania oraz interakcje z innymi współpracownikami.

A gdzie w tym wszystkim przestrzeń na code review? No właśnie, zazwyczaj w tak zwanym „międzyczasie”, czyli gdy znajdzie się chwila lub luka pomiędzy innymi obowiązkami. Problem w tym, że sprawdzenie kodu zwykle zajmuje więcej niż chwilę. Wykonanie wyłącznie statycznej analizy kodu w wielu przypadkach okazuje się ryzykowane i niewystarczające.

Zarezerwuj czas na code review

Postaraj się wyznaczyć sobie w ciągu dnia blok czasu, w którym skupiasz się wyłącznie na przeglądaniu i testowaniu kodu napisanego przez innych developerów. Nie musisz trzymać się sztywno konkretnych godzin. Nie ma też większego znaczenia ile taki blok będzie trwać. W końcu każdy z nas pracuje i zarządza swoim czasem w nieco inny sposób.

Dla jednych dobrym rozwiązaniem będzie zaczynanie dnia od analizy kodu. Czytanie przy porannej kawie kiedy umysł jest świeży i wypoczęty. Z kolei inni wolą zabrać się za to po południu lub na koniec dnia pracy. Każdy z tych sposobów jest dobry i tak naprawdę zależy od Twoich preferencji. Najważniejsze i tak jest to żebyś po prostu znalazł ten czas, w którym skupiasz się w 100% na robieniu code review.

Dobre code review, czyli jakie?

Czym więc jest owo „dobre code review”? Jak wspomniałem, samo przeczytanie kodu zazwyczaj nie wystarcza. Dlaczego? Dlatego, że nasze oko jest po prostu omylne. W gąszczu linii kodu bardzo łatwo umyka nam jakaś nieścisłość lub zwyczajnie przeoczamy coś ważnego. Statyczna analiza kodu może sprawdzić się jeśli pull request to tzw. „one-liner” albo oczywista zmiana w dobrze nam znanym obszarze aplikacji. Zakładam jednak, że na codzień recenzujesz również bardziej złożony kod, który wymaga głębszej analizy i zastanowienia.

W ślad za czytaniem kodu, powinno iść jeszcze jego przetestowanie. Nie wyobrażam sobie dobrego code review bez przełączenia się na gałąź, na której znajdują się zmiany. Mam na myśli nie tylko przejrzenie kodu w swoim IDE, lecz przede wszystkim przeklikanie i sprawdzenie działania kodu na lokalnym środowisku. Przetestowanie jak zmiany wpływają na zachowanie aplikacji. Może się zdarzyć, że dopiero wtedy wychwycisz błąd lub miejsce, które wymaga poprawek.

Kolejnym ważnym elementem dobrego code review jest sprawdzenie i upewnienie się czy testy dla obszaru aplikacji, w którym dokonano zmian wykonują się poprawnie (świecą na zielono). Wszak może zdarzyć się, że ich autor zapomniał napisać testy do swojego kodu. Wówczas wykonanie istniejących już testów może wskazać i pomóc znaleźć Ci miejsce, które wymaga ewentualnych poprawek.

Dopiero po uwzględnieniu wszystkich powyższych czynności jesteś w stanie stwierdzić, że wykonałeś dobre code review. Od razu zaznaczę, że nie zawsze każdy z powyższych kroków jest konieczny. Wszystko zależy od kodu, który recenzujesz. Chciałbym żebyś nie poprzestawał na czytaniu i po prostu pamiętał o tym by przetestować kod lokalnie w swoim środowisku.

Code review to świetna nauka (nie tylko dla juniora)

Juniorzy mają często przeświadczenie, że code review w ich przypadku działa tylko w jedną stronę. To znaczy, że ich (na razie) mniej doskonały kod idzie „pod topór” i oko bardziej doświadczonego developera. Sami zaś poproszeni przez seniora o przejrzenie jego kodu nie mają innego wyboru jak tylko kliknąć „approve” i dać akcept niejako w ciemno. Bo czytają przecież kod napisany przez seniora.

To niestety bardzo zły nawyk oraz zupełnie niepotrzebna obawa. W najgorszym przypadku Twój komentarz do kodu nie zostanie po prostu uwzględniony. I tyle, nic nie tracisz. Pomyśl za to ile możesz zyskać jeśli naprawdę wnikliwie przeanalizujesz kod, a tym bardziej jeśli wykryjesz błąd 😉

Zauważ, że robienie code review to też świetna nauka! Gdy napotykasz fragment kodu, którego nie rozumiesz, warto odezwać się do autora i poprosić go o wyjaśnienie. Dzięki temu rozwijasz się i pogłębiasz swoją wiedzę. Nie bój się pytać. Jako junior (nowa osoba w projekcie) patrzysz na kod z innej, świeżej perspektywy. Twoje uwagi mogą być bardzo cenne i wnieść wiele dobrego do projektu.

Nie spiesz się

Pamiętaj, że code review to nie wyścigi. Jeśli masz do przejrzenia kilka zmian, albo właśnie przed chwilą otrzymałeś kolejną prośbę o sprawdzenie, nie musisz robić tego natychmiast (chyba, że to hotfix produkcyjny) 😉 Po prostu weź głęboki oddech i poczekaj na moment dnia, gdy przełączysz się w tryb czytania i analizowania kodu. Uwierz mi, że code review robione pod presją czyni więcej złego niż dobrego.

Pamiętaj, że zawsze masz prawo odmówić zrobienia code review lub po prostu nie zdążyć go wykonać. Możesz zwyczajnie nie mieć na to czasu lub na przykład zostać poproszony o przejrzenie zbyt wielu zmian w danym momencie. Jeśli na przykład dany pull request wymaga sprawdzenia przez bardzo wielu developerów, może się okazać, że Twoja analiza nie jest konieczna, a jedynie opcjonalna. Warto więc podejść do tematu na luzie, bez nadmiernej presji i niepotrzebnej reaktywności.

Podsumowanie

Jak widzisz dobre code review wymaga wysiłku i skupienia. Jest tak samo ważną częścią codziennej pracy developera jak dopisywanie kolejnych linijek kodu. Niejednokrotnie zajmuje też sporo czasu, zwłaszcza jeśli analizujesz dużą i istotną z punktu widzenia aplikacji zmianę w kodzie. Nie przejmuj się więc i nie czuj winny jeśli sprawdzanie kodu zajmie Ci większość lub nawet cały dzień pracy.

Dobry kod wdraża się na wyłącznie wtedy gdy zostanie wcześniej należycie przeanalizowany i przetestowany. Dlatego tak ważne jest dobre i wnikliwe code review. Nie zaniedbuj tej czynności. Sprawdzaj kod każdego dnia i rób to coraz lepiej!

O robieniu dobrego code review dowiesz się również tutaj. A może chcesz wiedzieć jak ja sprawdzam kod? Jeśli tak, to napisz do mnie 🙂

Wojciech Pilich

Autor tego bloga. PHP Developer z pisarskim zacięciem. Wyznawca czystego kodu, a zwłaszcza zasad YAGNI i KISS. Pasjonat nowych technologii, fan Gwiezdnych Wojen, a po pracy miłośnik kotów syberyjskich. Z wykształcenia humanista, z zamiłowania programista.

Dodaj komentarz

*