Junior też powinien robić code review

Zdarza mi się zadać w trakcie rozmowy rekrutacyjnej pytanie dotyczące code review. Zwłaszcza jeżeli pytana osoba stwierdziła, że w poprzedniej firmie takowe robili. Pytanie jakie zadaję brzmi – czy widzisz sens w tym, żeby junior robił code review seniorowi i jeżeli tak to jakie są z tego korzyści?

Odpowiedzi na tak postawione pytanie są różne. Jednak większość, co moim zdaniem dobre, jest pozytywna i ludzie potrafią wymienić zalety takiego rozwiązania. Dlatego dzisiaj postanowiłem przybliżyć ten temat tym, którzy mają wątpliwości w tej kwestii.

Kiedyś już napisałem tekst na temat code review. Dotyczył on trochę innej jednak mimo wszystko łączącej się z dzisiejszym tematem kwestii. Także zapraszam również do niego.

Równi i równiejsi?

W zamierzchłych czasach, kiedy stanowiska w firmie miały tą samą moc sprawczą co pozycja na królewskim dworze zasady były proste. Cały kod, który powstawał musiał być zatwierdzony przez starszyznę plemienną. Wchodzący do projektu mogli co najwyżej mieć nadzieję na łaskawość oka tejże starszyzny, która bacznie przyglądała się ich kodowi. Zaś każda uwaga z ust młodszego stażem kolegi uznawana była za obrazę majestatu. Potem przyszedł edżajl i płaskie struktury…

I wtedy też sytuacja zaczęła się zmieniać. Skoro każdy w projekcie teoretycznie może być odpowiedzialny za każdy element systemu, zespoły są małe i każdy bierze udział w dyskusjach to rola starszyzny zaczęła się uszczuplać. Nagle ci młodzi stażem mają swój głos! Co więcej, firma zachęca do słuchania opinii każdego! Co to się porobiło w tym świecie.

Mniej więcej tak to może wyglądać z perspektywy osoby, która piastowała stanowisko starszego szamana w grupie. Nagle to nie tylko on decyduje o być lub nie być commita w repozytorium. Nagle to ktoś inny może się wypowiedzieć. A co najgorsze ktoś inny może skrytykować jego kod!

Na szczęście reszta zrozumiała sens takich zmian.

Junior też człowiek

I tutaj przechodzimy do istoty tematu. Kiedy w końcu programiści zrozumieli, że ktoś z mniejszym doświadczeniem też ma swoje zdanie to nareszcie takie osoby mogły również patrzeć na zmiany wprowadzane przez starszych kolegów. Bo sam fakt posiadania mniejszego stażu pracy w żaden sposób nie zmienia faktu, że taka osoba ma swoje spojrzenie na sprawę. Dodatkowo skoro ma z tym kodem pracować to dobrze żeby widziała co się w dzieje.

Code review z korzyścią dla ogółu

Dając juniorowi możliwość zrobienia code review kodu wprowadzonego przez bardziej doświadczonego programistę zyskuje ostatecznie cały zespół. W jaki sposób? Otóż powodów jest kilka. Mniej lub bardziej oczywistych jednak moim zdaniem wszystkie są istotne.

Poznanie struktury kodu

Mimo najszczerszych chęci i poświęcenia dużej ilości czasu nie zawsze da się pokazać nowej osobie wszystkie elementy projektu. Wskazanie tak na sucho jakiegoś miejsca w kodzie, które warto zobaczyć też może nie przynieść wystarczających rezultatów. Co innego kiedy junior dostanie do sprawdzenia wprowadzane zmiany. Po pierwsze jest wtedy pewność, że dotyczą one bieżącej pracy. Więc nie będzie sytuacji, że pokazaliśmy takiej osobie jakiś moduł i okazało się, że w sumie nikt do niego nawet nie sięgał od dawna. Tutaj junior widzi co jest zmieniane w danym sprincie czy po prostu w kontekście aktualnych zadań. Widzi więc kod, który jest teraz istotny.

Druga sprawa to zrobienie code review zachęca juniora do odnalezienia wprowadzanych zmian w projekcie. Mimo, że narzędzia do przeglądu kodu są coraz lepsze to wystarczy zasugerować po prostu poszukanie i otwarcie zmienianych plików w IDE. Jest to o tyle proste, że w trakcie code review chyba wszystkie narzędzia pokazują ścieżki do plików jakich dotyczą zmiany. W ten sposób mniej doświadczona albo po prostu nowa w projekcie osoba poznaje strukturę projektu niejako przy okazji – poznając w jakim kontekście znajduje się nowa porcja kodu.

Dzięki temu dużo łatwiej będzie mu wejść w aktualne zadania i przez to też taka osoba będzie szybciej odnajdować się w tym co ma zrobić.

Przyśpieszony kurs programowania

Nauka przez przykłady potrafi być bardzo efektywna. Dlaczego więc mielibyśmy uniemożliwiać juniorom korzystanie z niej? Oczywiste jest, że ktoś z mniejszym doświadczeniem nie zna wszystkich elementów języka czy frameworka. Pewnie nawet nie jest świadomy ich istnienia. Za to senior trzaskający zadanie za zadaniem wręcz automatycznie wybiera optymalne rozwiązania ze swojego bardzo bogatego zasobnika struktur kodu, bibliotek i funkcji.

Jest spora szansa, że junior robiący code review trafi na takie sprytne rozwiązanie albo zobaczy jakieś nowe dla niego słowo kluczowe. Co więcej zobaczy to rozwiązanie w praktycznym przykładzie użycia go! Czytając o nim w książce czy dokumentacji trudniej jest odnieść zalety zastosowania jakiejś konstrukcji w naszym kodzie. Tutaj wszystko jest podane na tacy, nic tylko chłonąć nową porcję wiedzy i jeszcze szybciej się rozwijać jako programista. A przecież każdy woli pracować z osobami, które mają większą wiedzę, prawda?

Świeże spojrzenie

Jeżeli ktoś pracuje w projekcie albo w jakieś technologii przez wiele lat to jest szansa, że automatycznie stosuje pewne rozwiązania poznane jakiś czas temu. Dając juniorowi do sprawdzenia swój kod jest szansa, że zobaczy on możliwość rozwiązania problemu w trochę inny sposób. W końcu on uczył się w innym czasie więc też mógł trafić na inne treści, z których pozyskiwał wiedzę. Nikt nie jest w stanie śledzić wszystkich nowości czy rozwiązań więc nawet mało doświadczona osoba potrafi zasugerować coś czego nie znaliśmy mimo lat doświadczenia. Warto więc umożliwić jej wykazanie się wiedzą.

Nieraz już widziałem komentarze dodawane przez juniorów do kodu bardziej doświadczonych osób gdzie pojawiały się sugestie innych sposobów rozwiązania zadania albo drobnych, może korzystających z nowszych rozwiązań sugestii.

Wady? Brak

Zalety które wymieniłem to na pewno nie wszystkie jakie idą w parze z code review robionym przez juniorów. Wiadomo, że nie zawsze możemy pozwolić żeby przegląd zrobiony przez taką osobę był jedynym wymaganym do zatwierdzenia danej zmiany. Jednak czy są jakieś wady takiego podejścia kiedy nie tylko starszyzna grupy może sprawdzać powstający kod? Według mnie jedyną wadą może być to, że czasami wyjdzie na jaw, że jakiś senior ma mniejszą wiedzę od świeżego kolegi ;) Ale czy to wada? Co najwyżej dla tego seniora, który liczył że sprawa się nie wyda.

Ważne jest tylko aby pomóc młodszemu koledze sprawnie takie code review przeprowadzić. Pokazać jak działają narzędzia do tego i na co powinien patrzeć.

A jakie jeszcze według Was są zalety dawania juniorom code review do zrobienia? Piszcie w komentarzach.