fbpx

Jakie są korzyści z dobrego Code Review

Opublikowane przez Jerzy Wickowski w dniu

Czym jest Inspekcja Kodu? Każdy wie lub może się szybko dowiedzieć, czytając na wikipedi. Zastanawiałem się ostatnio, czy czas poświęcony na tę czynność, mógłby być wykorzystany lepiej. Odpowiedź na to pytanie zależy od masy czynników. Takich jak podejście osób uczestniczących w procesie, czy specyfiki projektu. Postanowiłem zatem opisać rzeczy bardziej stałe, czyli jakie można osiągnąć korzyści z dobrego Code Review.

Redukcja Bus Factor

Nie zakładaj, że wypadki losowe nie dotyczą Ciebie i Twojego otoczenia. Wręcz przeciwnie. Rozsądniej będzie, jeżeli założysz, że zdarzają się często, bardzo często. Zatem warto wziąć pod uwagę, że nawet jutro ktoś z zespołu może zniknąć na bliżej nieokreślony czas. W związku czym, konieczne będzie przejęcie jego, prawdopodobnie rozgrzebanego, kodu. Tutaj z pomocą przychodzi właśnie Code Review, które jeżeli było przeprowadzone z pełnym zaangażowaniem to pozwala na bardzo szybkie wejście na ścieżkę, którą nieobecny miał w głowie.

Wymiana wiedzy w zespole

Ten punkt jest bardzo podobny do pierwszego, ale chciałbym się skupić na innej perspektywie. Załóżmy, że wpadnisz na jakiś sprytne rozwiązanie, dzięki któremu można zaoszczędzić masę czasu. Jeżeli masz siłę przebicia to możesz z tym wyjść na forum i przedstawić rozwiązanie całemu zespołowi. Natomiast, jeżeli brakuje Ci takiej cechy, to właśnie rewju jest naturalnym miejscem, gdzie taką wiedzę możesz przekazać lub pozyskać.

Zwiększenie czytelności

Jest to bardzo ważny punkt, bowiem pomaga on nie tylko autorowi i rewjułerowi, ale i każdemu kto będzie czytał ten kod w przyszłości. Zwracając uwagę na dobór odpowiednich nazw, poprawę struktury kodu, czy inne tego typu drobnostki podczas inspekcji. Oszczędzasz niewyobrażalną ilość czasu całych rzesz programistów, którzy będą ten kod rozwijać i utrzymywać. Proste i klarowne.

Sprawdzenie spójności rozwiązania

Często zaczynając rewju warto zadać pytanie w stylu „Po co pisałeś ten kod?”. Odpowiedź na nie pozwala zrozumieć kontekst wprowadzanej zmiany. Zweryfikować, czy oboje tak samo rozumiecie zadanie. Dodatkowo możesz patrzyć na wszystkie zmienione linie kodu w kontekście całego zadania, a nie na poziomie pojedynczych plików. Dzięki czemu kod po takim sprawdzeniu powinien być spójniejszy i bardziej logiczny.

Wyłapanie błędów i literówek

Jest to najczęściej wymieniana zaleta inspekcji kodu, jednak nie uważam jej za najważniejszą. Owszem podczas przeglądania kodu zdarza się znaleźć jakiś błąd, albo poprawić literówkę. Jednak o takie rzeczy powinna dbać, przede wszystkim, osoba pisząca kod. Owszem, Code Review jest w pewnym sensie siatką bezpieczeństwa, pozwalającą na wyłapanie drobnych niedociągnięć, ale uważam że warto szanować czas swój, rewiułera i pracodawcy.

Czy to wszystkie plusy? Z pewnością nie. To są te najważniejsze, o których staram się myśleć podczas każdej inspekcji. Uważasz, że jest jakaś kluczowa zaleta o której nie wspomniałem? Jeżeli tak serdecznie zapraszam do dyskusji.



Czy to był wartościowy artykuł? Bądź na bierząco. Zapisz się, a poinformuję Cię o nowych postach

2 Komentarze

Maciek S. · 2017-12-23 o 13:57

Dla mnie każda możliwość opowiedzenia o swoim kodzie jest na plus, w tym też w sytuacji Code Review, gdzie siadasz z kimś i gadacie o Twojej pracy. Wtedy jesteś zmuszony po raz kolejny zastanowić się nad tym, co wcześniej wyprodukowałeś. Jedna strona medalu jest taka, że osoba z zewnątrz widzi więcej niż Ty, który klepałeś kod, a druga, że Ty sam z perspektywy czasu możesz dostrzec coś, czego wcześniej nie było widać – jakieś możliwe punkty zapalne.

    Jerzy Wickowski · 2017-12-23 o 15:52

    @Maciek: Dzięki za komentarz. Zgadzam się z Tobą. Zwłaszcza jeśli chodzi o perspektywę innej osoby. o jest nieocenione!

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Zapisz się

Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.