Przegląd kodu (Code review) jest wspaniałą rzeczą, która jak wszystkie inne dobre rzeczy robione źle, może przynieść wiele szkód. Mimo wszystko, nie ma powodu do obaw, ponieważ poniżej znajdziesz listę rzeczy, których należy unikać, aby uzyskać najlepsze rezultaty podczas przeglądu kodu.

Przegląd kodu jest dobry

Code review ma potężną moc. Nie ma potrzeby się go bać, istnieje wiele artykułów o korzyściach, które przynosi. Większość ludzi zgodzi się, że przegląd kodu jest kluczowym procesem w osiągnięciu wartościowego kodu. Mniej ludzi zauważa pozostałe zalety, choćby takie jak wzrost umiejętności analitycznych programistów, umiejętności argumentacji, komunikacji, zdobywanie wiedzy w zespole i in. Jest to powszechnie uznane za dobrą rzecz. Jak szczotkowanie zębów.

Różni ludzie robią to inaczej

Niektóre zespoły przeprowadzają przegląd kodu jak dodatkową czynność, zalecaną lecz niewymaganą. Niektórzy team leaderzy przydzielają parę godzin wydajności na ten proces i silnie zachęcają programistów do wzajemnego przeglądania kodu. Są także organizacje, w których dany proces jest obowiązkowy: kod stworzony przez programistę musi być zrecenzowany przez jednego lub paru kolegów z pracy, zazwyczaj tych z większym doświadczeniem i musi być zaakceptowany przed włączeniem do kodu całkowitego. Nie ma potrzeby dyskusji, czy jest to przesada czy jedyny rozsądny sposób, by stworzyć oprogramowanie, jako że było już mnóstwo dyskusji na ten temat. Jednak niektóre organizacje przywiązują właśnie taką wagę do przeglądu kodu: nie zaakceptują niezrecenzowanego kodu, opóźnionej produkcji kodu, spowalniania procesu programowania. Prawdziwie wierzą w moc przeglądu kodu.

Wielka władza ciągnie za sobą wielką odpowiedzialność

Wszyscy to doskonale wiedzą już od czasów pierwszego filmu o Spider-Manie. Przegląd kodu nie jest rzeczą łatwą. Recenzent musi zrozumieć potrzebę, która prowadzi programistę do napisania tego kodu, co nie jest niczym łatwym, ponieważ oprogramowanie jest wysoko skomplikowanym tworem. Programista musi wytłumaczyć swoją potrzebę i zasadność wyborów, na które się zdecydował podczas pisania kodu. To także nie jest łatwe. Bez popadania w stereotypy można powiedzieć, że większość programistów ma problem w jasnym wytłumaczeniu ich wyborów podczas pracy. Szczególnie tych podjętych wiele lat temu, które na dzień dzisiejszy stały się przyzwyczajeniem.

W większości recenzowanie jest trudne dla ego

Kiedy dwoje ludzi prowadzi dyskusję na temat kodu, jeden z nich musi być za, a drugi przeciw. To brutalne. Sytuację pogarsza fakt, że recenzent jest postrzegany z pozycji władzy: jest to zazwyczaj bardziej doświadczony programista, czasem lider zespołu, który przyszedł "ulepszyć" kod. Przegląd kodu może pójść w złą stronę i wywołać dramatyczne konsekwencje: złe relacje w miejscu pracy, napięcia, niezadowolenie, poczucie braku kontroli, poczucie braku posiadania kodu oraz braku zaangażowania itp. Człowiek przekonany wbrew własnej woli w dalszym ciągu będzie miał własne zdanie. A także będzie rozgoryczony.

Podstawowa teza w tym wszystkim

Zapamiętaj te słowa: przegląd kodu, nawet jeśli znacznie poprawia kod kosztem stosunków w pracy i dobrego nastroju programisty nie jest wart przeprowadzenia. Ulepszenie wybranej części kodu na środę wieczór nie jest główną korzyścią przeglądu kodu. Tworzenie i podtrzymywanie dobrych relacji pomiędzy pracownikami podczas współpracy i mentorowania młodszym programistom - to są główne cele, dzięki którym można osiągnąć o wiele więcej.

Wywieranie wpływu nie jest łatwym zadaniem.

Oczywiście, mam na myśli dyplomatów i polityków, ponieważ dla programistów jest to zadanie spoza ligi. Przejście na otwarte wygłaszanie swojego punktu widzenia, uważanie go za oczywisty oraz wymuszanie go na innych, wywieranie wpływu i udzielanie wsparcia zdecydowanie nie jest tak proste jak nauka nowego języka programowania. Ale nie martw się, można poradzić sobie z tym w taki sam sposób, jak na uczelni, przy pomocy ściągi.

Po prostu nie rób niczego, co jest napisane niżej,

1. Przesadna generalizacja

Zauważenie, że coś jest nie tak i wyolbrzymianie tego przez generalizację:

• Czy to jest to, czym się teraz zajmujemy, budowanie interfejsów dla wszystkich klas?
• Do czego to ma doprowadzić, do pakowania wszystkich klas SDK?

Nie generalizuj przed zaobserwowaniem ewidentnego, powtarzalnego zachowania, bo jest to krzywdzące. Zacznij od założenia, że code writer ocenia każdą sytuację osobno.

2. Osobiste upodobania

Powoływanie się na osobiste upodobania jest łatwą drogą do uniknięcia konfrontacji i starań w znalezieniu logicznych argumentów.

• To tylko moja osobista opinia, że powinniśmy to zrobić właśnie w taki sposób.
• Zawsze lubię robić to w ten sposób, myślę, że może ci się to spodobać.

Recenzent kodu musi zawsze używać logicznych argumentów, porównać korzyści do strat i wskazać ogólnie przyjęte referencje, na przykład wartościowe książki (Clean Code, Effective Java lub inne).

3. Bycie głuchym na potrzeby autora

Żadne rozwiązanie nie jest bezbłędne bez poniesionych kosztów. Lecz nie można tego naprawić, w ogóle nie posiadając kodu. Autor potrzebuje rozwiązania, a obecny kod nie może być odrzucony bez podania alternatywy.

• Nie rozumiem, dlaczego tego potrzebujesz, ale to nie wygląda dobrze.
• Nie chcę tego, znajdziemy odpowiednie rozwiązanie innym razem, ale to nie wygląda dobrze. Później do tego wrócimy.

Takie zachowanie bezpowrotnie wyprowadzi code writera z równowagi. Jeśli nie ma czasu na lepsze rozwiązanie, obecne rozwiązanie jest najlepsze.

4. Oskarżenia o bycie władczym

• Problem jest taki, że chcesz wyłącznie potwierdzić swoją wersję.
• Nie lubisz, gdy ktoś podaje w wątpliwość twój kod.

To zachowanie obniża jakość debaty i korzystniej byłoby przerwać przegląd.

5. Pozycja władzy

Używanie pozycji władzy popartej doświadczeniem bądź stanowiskiem zamiast argumentów nie przekona programisty. Wręcz odwrotnie, spowoduje, że zakwestionuje on kompetencje recenzenta.

• Uwierz mi, z własnego doświadczenia wiem, że to lepsze rozwiązanie.
• Zrozumiałem o co ci chodzi, mam własne zdanie, lecz w końcu to ja jestem liderem zespołu.

Co robić gdy jest remis?

Co się dzieje, gdy właściwe, logiczne argumenty są proponowane przez obie strony, lecz żadna ze stron nie jest przekonana przez drugą stronę? W tym wypadku doradzam, by kod pozostał niezmieniony. Dlaczego? Ponieważ podczas kodowania autor włożył w to wysiłek i bardziej by go dotknęło, gdyby musiał zmienić kod wbrew własnej woli. Pamiętaj że prawda jest zazwyczaj unaoczniana, rzadziej wypowiadana. Jeśli po paru tygodniach problemy z kodem wypłyną na powierzchnię, code writer będzie pamiętał o sugestii recenzenta i ostatecznie ją zaakceptuje.

Czy to ma w ogóle jakiekolwiek znaczenie?

W pewnym stopniu ma. Źli recenzenci będą unikani przez swoich kolegów z pracy. Ludzie będą szeptać, że ten zły recenzent nie włącza się do dyskusji. Recenzja to trudne doświadczenie. Nikt nie jest złym recenzentem z wyboru, niektórzy programiści skupiają się wyłącznie na stronie technicznej przeglądu i zapominają o byciu delikatnym i pełnym szacunku w stosunku do swoich kolegów z pracy. Czasem są bez skrupułów.

Dobry recenzent jest śmiały - wyraża swoją opinię i poświadcza ją, lecz jednocześnie jest taktowny w stosunku do code writera. Jest lubiany nawet przez tych, którzy się z nim nie zgadzają i spontanicznie pyta się go o opinie. Daje wspaniały przykład współpracy przy kodzie i pod wieloma względami wpływa na programistów w widoczny sposób. To czysta magia!

Ionut Bilica
Software Development Consultant