PR Review - Powody występowania
Wspólnie z Krzysztofem Witczakiem stworzyliśmy serię artykułów, w których zastanawiamy się skąd tak duża popularność Pull Request Review, oraz jakie problemy Pull Request Review tworzy w naszych zespołach. Następnie podjęliśmy temat rozwiązywania kwestii PR Review i mierzenia, czy jest lepiej.
W serii PR Review:
Powody występowania [TEN ARTYKUŁ]
W poprzedniej części serii pisaliśmy o genezie PR Review a także mniej lub bardziej oczywistych pułapkach, które za tym podejściem stoją. Dziś przyjrzymy się bliżej powodom występowania.
Powody występowania PR Review
Przede wszystkim, podobnie jak inne dobre praktyki, wiele zespołów akceptuje status quo i wykonuje review, ponieważ takiej formy pracy ich nauczono i nikt tego nigdy nie zakwestionował, ani nie zastanowił się, czy nie da się inaczej 😉
Code Review stało się tożsame z PR
Ciężko jest sobie dzisiaj wyobrazić lidera technicznego, który z dumą podzieli się z kolegami, że nie robi PR code review. Taka deklaracja szybko zostałaby okrzyknięta antywzorcem, cięciem po jakości, zrzucając lidera do pozycji defensywnej.
Dobre umiejętności robienia PR code review są dzisiaj weryfikowane i oceniane podczas rozmów o pracę jako jeden z obszar seniority kandydatów, a u liderów są oczywistym wymogiem – i w niemal każdym przypadku jest to tożsame z PR.
Zaskakujące jest jak rzadko spotyka się liderów, którzy omawiają inne sposoby dbania o jakość kodu – a przecież nikt nie powiedział, że review musi się dziać wyłącznie podczas PR.
Kultura single ownership
Kultura single ownership i duży WiP przez jednostkowe przydzielanie zadań. Zaletą jest na pewno to, jak wiele zmian jest naraz wdrażane.
W takim modelu każdy programista ma swoje zadania. Rzadko współpracuje nad kodem z innymi. Zmniejsza to wspólną odpowiedzialność za jakość kodu, więc wolimy sprawdzić kogoś innego kod raz a dobrze.
Dodatkowo każdy chce stworzyć wymuskany kod by pokazać pracę zakończoną. Nie chce się dzielić czymś w połowie zakończonym, bo ktoś inny go skrytykuje i powie, że brakuje jeszcze A, B,C (pomimo tego, że jest to opisane w komentarzu do PR – kto je ma czas czytać, jak trzeba czytać kod? 😉) A jeżeli jesteśmy oceniani (bo prezentujemy “skończoną” pracę), no to chcemy pokazać się z najlepszej strony.
Brak zaufania / bezpieczeństwa psychologicznego
W Open Source nigdy nie wiemy, kto jest po drugiej stronie, jak dobrze zna repozytorium, jakie ma intencje oraz czy jest to jednorazowa kontrybucja czy długotrwała relacja. Nic dziwnego, że poziom zaufania jest niższy.
W miejscu pracy sytuacja jest inna - jesteśmy w jednej organizacji, mamy dostęp do wspólnych narzędzi, standardów, mentorów i wspólne cele. Jeżeli dalej nie mamy zaufania, może to wynikać z różnych powodów:
Kontrybutor ma mniejsze doświadczenie i czujemy potrzebę kontroli. Jak długo ta kontrola jest potrzebna?
Kontrybutor ma niższe standardy jakości. Z czego to wynika? Dlaczego pojawiają się te same błędy? Czy ciągły gate-keeping zmian w nadziei na poprawę to skuteczna metoda? Może jako liderzy powinniśmy spróbować czegoś innego?
Może to też wynikać z konfliktów, ego, statusu reviewera (potrzeba kontroli, nadążania za zmianami, trzymania ręki na pulsie) – w każdym przypadku należy się zastanowić, dlaczego approval jest konieczny, i czy problem nie leży w nas samych. Może da się uzyskać podobne lub lepsze rezultaty w inny sposób? Dokładny PR review to ciężka praca, ale jak to się przekłada na efekty?
Z naszego doświadczenia, problem braku zaufania występuje szczególnie często w zespołach zdalnych.
Błędne incentive dla pracowników
Organizacje chcą w jakiś sposób skwantyfikować mierzenie efektywności pracowników. Robią to w sposób, który kodyfikuje wykorzystywanie PR Review.
Wielokrotnie to sama organizacja wprowadza metryki czy zachowania, które utrwalają PR code review w swojej postaci. Często będzie to mierzenie approvali, ilości komentarzy, zaangażowania czy czasu poświęconego na review. Oczekujemy, że programiści, którzy chcą awansować, aby stać się seniorami lub liderami będą często i dokładnie “trzepać” podczas PR review, bo to główny sposób w jaki postrzegamy dbanie o jakość wprowadzonych zmian i zaangażowanie.
Naturalnie, metryki te mają na celu zbalansowanie wysiłku pomiędzy członkami zespołu, odkrycie osób najbardziej zaangażowanych i takich, które pomagają odblokować innych członków zespołów. No i oczywiście, gdyby code review było umiejscowione w innym miejscu w SDLC, nikogo nie trzeba byłoby odblokowywać!
Nieświadomie, management wywiera presję na zespoły, aby utrzymały status quo, a u młodych liderów wzmacniają znaczenie przypisywane PR code review.
Zmiana musi się wyleżeć by była jakość
W branży istnieje wyobrażenie, że zawsze godzimy się na jakiegoś rodzaju kompromis pomiędzy jakością i szybkością:
Zwiększamy prędkość dostarczania. Jednocześnie dostarczamy gorsze rozwiązanie – idziemy na skróty, zaniedbujemy przypadki brzegowe, coś działa nieprawidłowo.
Zwiększamy jakość rozwiązania. Jednocześnie dostarczamy wolniej – zamiast dostarczać w cyklach dziennych to wchodzimy na produkcję o wiele rzadziej.
Dbanie o zapewnianie jakości dzieje się kosztem prędkości.
Wobec czego chcąć posiadać wysoką jakość musimy ją wprowadzać wolno. Więc wolne PR Review nie jest tu problemem.
Review jako remedium planowania
W wielu zespołach zwinnych stosujemy założenie, że “User Story” może być stosunkowo ogólnie napisane, a dobry senior sam zaproponuje rozwiązanie.
To prowadzi do sytuacji, gdzie reszta zespołu rozmawia faktycznie o implementacji dopiero mając ją już przed oczami na PR review.
Powodów takiej sytuacji jest wiele:
chęć dania wolności programistom w implementacji,
niechęć do biurokratycznego podejścia do analizy zadań,
łatwość komentowania rozwiązania, gdy mamy implementację przed oczami,
mniejsza liczba uknown uknowns na tym etapie.
Gdy wejdziemy dostatecznie głęboko, to często okazuje się, że wielu błędnych decyzji i spalonych godzin można było uniknąć.
Jeżeli całe planowanie prac w zespole ogranicza się jedynie do krótkich sesji groomingowych, to PR review w oczach liderów jest niezbędną bramką, aby weryfikować jakość… ale czy nie da się robić tego lepiej, wprowadzając mniejszy waste?
Ucieczka w Review
Nasza praca często jest bardzo męcząca kognitywnie, wielokrotnie musimy dokonywać trudnych decyzji i nie mamy na to energii. Dla niektórych programistów “ucieczka w review”, zwłaszcza w taki skupiony na problemach stylistycznych, to próba odpoczynku bądź prokrastynacji od trudniejszych aktywności.
Podobnie jak wcześniej, PR review staje się plastrem na inne problemy.
Faktycznie ma ono sens
To zostawiliśmy na koniec 😀
PR Review jest narzędziem jak każde inne. Istnieją scenariusze (wymienione również wyżej), w ramach których ta praktyka ma sens.
Wspomniane już projekty Open Source, gdzie nie znamy kontrybutorów i nie możemy po prostu zaufać
Wdrażanie nowego pracownika przez określony czas
Dotykanie krytycznych obszarów które w przypadku prostego błędu mogą wywołać wiele szkód (np. pliki konfiguracyjne produkcji)
Zmiany wyjątkowo niepewne i trudno odwracalne, gdzie autor pomimo wcześniejszego planowania chciałby skonsultować się z kilkoma osobami (np. skomplikowane migracje)
Propozycje implementacyjne, czyli PR, który niekoniecznie musi być mergowany ale którego review ma wywołać dyskusję w zespole na określony temat (np. może piszmy testy w ten sposób?) i gdzie zapewnić sobie mieć łatwość asynchronicznej dyskusji
Jak mierzyć usprawnienia dookoła PR Review?
Zanim zabierzemy się za rozwiązywanie tych wszystkich problemów, warto najpierw dowiedzieć się jak je dokładnie zdefiniować. O tym piszemy w kolejnej części serii.