Code Review to praktyka, która powinna mieć miejsce w każdej firmie programistycznej. Przynosi ona wszakże bardzo dużo pożytku każdej ze stron biorących w niej udział: zapewnia lepszą jakość kodu, trzymanie się standardów panujących w firmie, rozwój umiejętności i wiedzy programistów.
Zatem jeśli Code Review przynosi tyle pożytku to czemu wiele firm nie stosuje tej praktyki lub jest ona marginalizowana? Niestety wina za ten stan rzeczy leży po naszej stronie – stronie starszych programistów, którzy oceniają młodszych programistów. Właśnie, oceniają młodszych programistów, a powinni oceniać kod młodszych programistów.
Code Review może ranić uczucia
Każdy z nas jest świadomy, że każdy kawałek kodu napisał człowiek, a nie maszyna (przynajmniej tak jest na razie :D). Człowiek, w przeciwieństwie do maszyny, ma uczucia i jeśli będziemy negatywnie oceniać jego poczynania, to Code Review przyniesie złość, zamknięcie się w sobie, nawet depresję, a nie rozwój, jakość i wiedzę.
Ten sam problem obserwuje środowisko Open Source i Start-upów. Każda publiczna paczka czy pierwsze MVP poddawane jest często bardzo surowej krytyce ich autorów, a nie samego kodu/rozwiązania. W takiej sytuacji feedback zamiast dawać wskazówki na ulepszenie biblioteki/startupu to podcina skrzydła. A przecież pozytywny feedback, czy konstruktywna krytyka to coś, czego każdy z nas oczekuje. Dlaczego zatem, jak jesteśmy po drugiej stronie, tak do tego nie podchodzimy? Nawet jeśli ktoś popełnił oczywisty błąd to zamiast zwrócić uwagę, że tam jest błąd, częstą reakcją jest komentarz, że ktoś jest po prostu słaby/nieprofesjonalny.
Ta sama sytuacja ma miejsce, gdy ktoś korzysta z mało popularnego/lubianego narzędzia/frameworka/systemu. Środowisko od razu wyczuwa taką ofiarę, jak stado wilków i przypuszcza atak. A czemu w ogóle ktoś wrzucił bibliotekę open source na GitHuba? Żeby zostać zaatakowany że użył rozwiązania X, a nie Y, że nie wykorzystał wzorca projektowego Z? Czy żeby ktoś skorzystał z przygotowanego przez niego rozwiązania, a ktoś bardziej doświadczony wskazał miejsca, które można poprawić? Zdecydowanie to drugie.
Jak robić Code Review?
W takim razie zastanówmy się jak przeprowadzić Code Review, żeby było konstruktywne i miało efekty wyłącznie pozytywne, nie negatywne
Wyłącz autora z równania
Gdy używamy zaimków: ja i ty, wszystko co napiszemy może być traktowane przez drugą osobę personalnie. Gdy napiszemy: “Powinieneś użyć tutaj wzorca Adapter” to autor kodu może odebrać to osobiście jako krytykę, nawet jak nie miałeś w ogóle takiego zamiaru.
Dlatego powinniśmy wystrzegać się zwracania w czasie Code Review osobiście. Znacznie bezpieczniejsze jest użycie zaimka my: “Powinniśmy użyć tutaj wzorca Adapter”. Jednakże i w tym rozwiązaniu czają się niebezpieczeństwa, bo jeśli osoba przeprowadzająca Code Review nie ma autorytetu lub nie bierze udziału w projekcie, to taka uwaga może być odebrana negatywnie, jako próba wejścia do zespołu projektu lub wywarcia na nim wpływu.
Pozostaje więc najbezpieczniejsza opcja: użycie formy osobowej: “Powinien tutaj być użyty wzorzec Adapter”. Takie zdanie nie budzi emocji, nie zostanie odebrane negatywnie i przede wszystkim przekaz jest jasny i autor kodu może się skupić na jego treści.
Przekaż komunikat bez emocji
Kolejnym aspektem komunikacji jest wartość emocjonalną jaką niesie wiadomość. Jeśli wydźwięk naszej wypowiedzi będzie zawierał cynizm, brak cierpliwości, krytykę czy nawet podekscytowanie, może wpłynąć na stan emocjonalny drugiej osoby.
Jeśli napiszemy komentarz: “Wykonuje się tutaj 8 zapytań do bazy, które nie tylko opóźnią ładowanie się strony, ale są też kompletnie niezoptymalizowane!” to nie możemy się spodziewać, że autor z radością usiądzie do optymalizacji kodu.
Ten sam komunikat można napisać inaczej: “Wykonuje się tutaj 8 zapytań do bazy. Może to spowolnić ładowanie się strony. Dodatkowo zapytania można zoptymalizować. Zajmiesz się tym?”. Dzięki takiej konstrukcji wypowiedzi – spokojnej, bez emocji, konstruktywnej, z oczywistym wezwaniem do akcji – autor kodu wie co ma zrobić i dlaczego. I wyciągnie wnioski na przyszłość.
Oceniaj kod, nie autora
O tym już pisałem wcześniej, omawiając główny problem z Code Review. Nie oceniajmy autora kodu, bo to nie jego oceniamy. Naszym zadaniem jest danie konstruktywnego feedbacku do kodu, który dostaliśmy do oceny.
Także jak zobaczymy kawałek kodu, gdzie przydałby się wzorzec X to nie piszmy komentarza w stylu: “Powinien tutaj być użyty wzorzec X. Naucz się wzorców projektowych!”, gdyż mamy tutaj zarówno krytykę (nawet jeśli niezamierzoną), a także odciągamy skupienie programisty od problemu: nie użycie wzorca X.
Lepszym rozwiązaniem byłoby napisanie pierwszej części komentarza i naszkicowania szybkiej implementacji kodu. Ale też nie naszym zadaniem jest poprawiać kod czy tworzenie całego rozwiązania. Krótki pseudokod nakieruje programistę na dobre tory i pokaże nasze zaangażowanie.
Dodatkowo:
- Ustalcie wewnątrz firmy jak najwięcej standardów kodu. Dzięki temu Code Review będzie prostsze, szybsze i bardziej obiektywne.
- Pamiętajmy, że dobre praktyki parę lat temu teraz mogą być uważane obecnie za złe. Dbaj o swoją wiedzę i bądź gotów na spokojną dyskusję, jeśli ktoś ma inne zdanie.
- Starajmy się by kawałki kodu poddawane Code Review były jak najmniejsze. Dzięki temu cały proces będzie prostszy, szybszy i łatwiejszy dla obu stron.
Code Review podsumowanie
Code Review to bardzo ważna praktyka w firmie, która ma mnóstwo zalet, a odpowiednio przeprowadzana praktycznie nie ma wad. Gorąco zalecam by stosować ją zawsze, nawet gdy deadline’y się zbliżają lub nie mamy czasu. W długiej perspektywie to podejście zawsze przyniesie więcej dobrego, niż złego.
Pamiętajmy tylko o tych kilku zasadach, o których wspomniałem powyżej, a Code Review w Twojej firmie będzie kojarzyć się wyłącznie pozytywnie jako praktyka do zdobywania wiedzy i doskonalenia umiejętności programistycznych zespołu. Powodzenia!
Artykuł powstał dzięki:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz