Przeczytaj wersję webową.

PR Review – historia, problemy i powody

Cześć!

Ta edycja newsletteru jest współtworzona wraz z Krzysztofem Witczakiem. Wspólnie zastanawialiśmy się skąd tak duża popularność Pull Request Review. Oraz jakie problemy Pull Request Review tworzy w naszych zespołach. W ramach kolejnego wydania podejmiemy dodatkowo temat rozwiązywania kwestii PR Review i mierzenia, czy jest lepiej.

Standardowo, czeka Ciebie również Inżynierska Prasówka.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀

Inżynierska prasówka

Rozpoczniemy od praktyk dookoła systemów rozproszonych. Zakończymy wywodem o tym, dlaczego platformy nie mają znaczenia. A pomiędzy tym MVP, ciekawa refaktoryzacja za pomocą AI i rant na mikroserwisy.

1. Busy Architect’s Guide to Distributed Systems - Ted Neward
   Część autorów stara się przekazywać wiedzę za pomocą kolorowych wykresów i animacji. Jednak nie zawierają w nich żadnych treści. Nie u Teda.
   Tutaj jest samo mięso techniczne podane tak krwiście (surowo) jak tylko można. Świetna prezentacja o problemach z zarządzaniem stanem, formatach komunikacji, modelach interakcji i wielu innych.
   „Distributed systems are really about distributed state” – to do mnie mocno trafiło.
   https://youtu.be/dW9Txa2rdjQ?si=5kKxcjogBHVAMFrA

2. The MVP Death Spiral – Tom Kerwin
   MVP powinno być małe z zasady. Ale czy to wystarczy? Jeśli udało Ci się przeczytać ostatnie wydanie newsletteru, to wiesz, że to nie wystarczy. Tom świetnie pisze o tym w jaki sposób MVP wpędza firmy w spiralę śmierci. Brak mierzenia, skupienie tylko na dowożeniu, scope creep. To niestety codzienność pracy z MVP.
   „Stop trying to pick the right features to make your product awesome. Start trying to enable the right behaviours to make your customer awesome.” – tak trzeba żyć :D
   https://open.substack.com/pub/triggerstrategy/p/the-mvp-death-spiral

3. AI-Powered Conversion from Enzyme to React Testing Library at Slack - Sergii Gorbachov
   Slack musiał zmigrować swoje testy z frameworku Enzyme do React Testing. I postanowił do tego wykorzystać AI. A na koniec opisał to wszystko na blogu.
   System był w stanie dojśc do automatycznej konwersji na poziomie 22 % test case’ów, które przeszły. Z pozoru wydaje się to nie wiele, ale wyobraź sobie, ile godzin manualnej pracy zaoszczędzono. A to dopiero początek. https://slack.engineering/balancing-old-tricks-with-new-feats-ai-powered-conversion-from-enzyme-to-react-testing-library-at-slack/

4. You probably don’t need Microservices - Bruno Costa
   W 2016 roku przeprowadziłem swoją pierwszą prezentację o tym, że nie potrzebujesz rozpoczynać od mikroserwisów. I nawet po latach uważam, że dalej warto pisać takie posty, ponieważ historia kołem się toczy.
   Bruno świetnie wyjaśnia powody, dla których nie musisz startować od systemu rozproszonego. Jednak najciekawsza jest opinia na samym końcu: „In a post-ZIRP era, I expect people to be more aware of the hidden costs of microservices.” – pożyjemy, zobaczymy 😉
   https://www.thrownewexception.com/you-probably-dont-need-microservices/

5. Why Platforms Don’t Matter - Bryan Finster
   Tytuł wydaje się clickbaitem, ale Bryan ma dużo racji. Platforma to tylko element w o wiele większej układance. Platforma nie rozwiąże problemów dookoła braku strategii, słabego zarządzania jakością czy silosów organizacyjnych.
   Wdrażając platformę bez zaadresowania elementów dookoła wdrożymy rozwiązanie, które nie dowiezie żadnych celów organizacyjncyh.
   https://www.youtube.com/watch?v=zk3IDsTkyK0

PR Review – z czym pracujemy

Z Krzyśkiem Witczakiem złapaliśmy się na Mastermind po publikacji na LinkedIn artykułu Pull Request Review - szybciej, lepiej, inaczej. Wymieniliśmy się spostrzeżeniami wokół problemów dookoła PR Review i jak poprawić ten stan rzeczy.

Wyszło z tego tyle notatek, że postanowiliśmy podsumować te informacje dla potomnych 😀

Jedna istotna uwaga:

• Nie skupiamy się tutaj na Pull Request – wystawieniu kodu do zmergowania po przejściu buildu
• Skupiamy się na Pull Request Review – procesie asynchronicznego sprawdzania kodu w ramach wystawionego PR.

Lecz najpierw krótka historia o tym, skąd PR Review się wzięło. I dlaczego jest ważne, by o tym pamiętać.

Historia Pull Request

Ciekawe podsumowanie historii PR możemy znaleźć na blogu Daniela Smith’a w artykule A Brief History of the Pull Request.

Git

Git został stworzony przez zespół pracujący nad jądrem Linuxa. Wraz z nim powstała też komenda Pull Request, aby uporządkować proces zgłaszania zmian. Wewnętrzni i zewnętrzni kontrybutorzy mogli tą prostą komendą zebrać proponowane zmiany do repozytorium. Następnie mieli możliwość je przesłać mailowo na listę mailingową Linux Kernel Mailing List. Tam oceniali ją natomiast główni maintenerzy.

Istotne jest wychwycenie tutaj kontekstu pracy nad jądrem Linuxa:

• Duża różnorodność kontrybutorów.
• Kontrybutorzy nie znają się wznajemnie.
• Środowisko mocno asynchroniczne – nieskupione na projektach, wydaniach.

Przy takich założeniach zadaniem jest oczywiście szukanie błędów i wychwytywanie wrogich aktorów..

GitHub

Następnie, w 2008 roku, powstał GitHub. Same Pull Request zostały wdrożone niewiele później – Oh yeah, there’s pull requests now. Zawierały jednak tylko powiadomienia mailowe do osób wskazanych w GUI.

Aktualny kształt Pull Request przyjął w 2010 roku podczas aktualizacji Pull Requests 2.0. Mamy znane nam dyskusje, commity, zmienione pliki:

Jednak znamienity jest opis zawarty w oryginalnym powiadomieniu od GitHuba:

As of today, pull requests are living discussions about the code you want merged. They’re our take on code review and represent a big part of our vision for collaborative development.

Pull Request został bezpośrednio powiązany z przeprowadzeniem sprawdzenia kodu.

Jeśli zaś skupimy się na repozytorach firmowych to jednak kontekst pracy się zmienił:

• Wąskie grono kontrybutorów.
• Grupa zwykle się zna, jest powiązana wspólnymi kontraktami.
• Środowisko synchroniczne – wydania, projektowa.

Więc skąd wykorzystanie PR w ramach sprawdzenia kodu?

Otoczenie narzędziowe 2010

Na powyższą sytuację trzeba nałożyć realia roku 2010.

W ramach tamtejszej sytuacji brakowało:

• Możliwości łatwej współpracy zdalnej – narzędzia typu Skype były jeszcze w powijakach.
• Potężnych IDE - wspomagających i automatyzujących naszą pracę.
• Procesów CI/CD – stale integrujących kod i sprawdzających błędy.
• Stabilnych środowisk testowych (nie mówiąc o efemerycznych).

Książki takie jak Continuous Delivery dopiero co wprowadzały tematy automatyzacji pod strzechy, tempo wypuszczania oprogramowania było mniejsze. Dużo więcej było więc wymagane od szeregowego pracownika – manualnego potwierdzenia, uruchomienia lokalnie, sprawdzenia testów.

Otoczenie narzędziowe 2024

Wszystko to, co zostało opisane powyżej jako braki, dziś już w zasadzie jest w standardzie. Mamy nowoczesne narzędzia (a nawet AI). Diametralnie zmieniło się też tempo dostarczania.

Więc czemu ludzie wciąż wykorzystują Pull Request Review w 2024 roku, w ten sam sposób co w 2010?

Ciężko powiedzieć.

Ale mamy kilka teorii. O nich za chwilę - gdy już opowiemy jakie problemy może zrodzić Pull Request Review stosowane jak w 2010.

Problemy dookoła PR Review

Konflikt interesów

Review staje jest poklepywaniem po plecach.

Autor czekający na review często już pracuje nad kolejnym zadaniem i chce jak najszybciej “wypchnąć” wiszące zmiany. Jakiekolwiek uwagi w review są tutaj opóźnieniem. A czas uruchomienia funkcji na produkcji jest widoczny dla wszystkich członków zespołu. Reviewer również jest tego świadomy.

Dodatkowo nierzadko dochodzi do błędów kognitywnych dookoła kosztu utopionego – Sunk Cost Fallacy:

Im więcej uwag znalezionych w kodzie tym mocniej zmieniamy napisany kod. Kod, na który poświęciliśmy czas by go napisać. Więc naturalnie będziemy chcieli z tym kodem iść dalej na produkcję.

W efekcie tworzymy środowisko, gdzie:

• Autor zmiany skrycie ma nadzieję, że nic “dużego” nie zostanie wykryte.
• Reviewer mający pomóc utrzymać jakość często “ogranicza” się, aby nie pogarszać sytuacji i nie doprowadzać do irytacji członka zespołu.

W takim środowisku błędne zmiany nie będą zawracane, ponieważ ich koszt socjotechniczny będzie zbyt duży.

Nie dowozi jakości produktu

Rozwijając poprzedni punkt, PR Review daje złudne poczucie jakości produktu.

• Nasze systemy stają się coraz większe i coraz bardziej skomplikowane z każdym rokiem.
• Liczba przypadków użycia i scenariuszy brzegowych staje się zbyt duża, aby mogła zostać w pełni pokryta podczas prostego przeglądu kodu, na który mamy mało czasu i robimy po oderwaniu od innej czynności.
• Często przypadki testowe wychodzą poza zmiany kodu – są połączone z częściami nie zmienianymi.

Możemy zacytować tutaj naukowców z pracy Alberto Bacchelli i Christian Bird Expectations, Outcomes, and Challenges of Modern Code Review”

Quality Assurance: There is a mismatch between the expectations and the actual outcomes of code reviews. From our study, review does not result in identifying defects as often as project members would like and even more rarely detects deep, subtle, or “macro” level issues. Relying on code review in this way for quality assurance may be fraught.

W rezultacie, istotne błędy mogą zostać przeoczone, a złudne poczucie bezpieczeństwa i jakości prowadzi do problemów w produkcie końcowym. PR Review wielokrotnie to tylko minimum, “plaster” na problemy zespołu związane z faktycznym dbaniem o jakość produktu.

Różne percepcje jakości

Znane nam są przypadki, gdy zespół ma tak zwaną “tribal knowledge”: kto w teamie robi dokładny review, a kto “rozdaje approvale” 😉 To tworzy sytuacje, w których:

• PR review jako ostatni bastion jakości łatwo złamać, jeżeli wiesz kogo zapytać…
• W zespole powstaje dysbalans wysiłku, uczucie frustracji, “jedni się starają” a inni nie
  • Ci którzy się starają, nie rozumieją, dlaczego innym nie zależy na jakości
  • Ci którzy dają approvale, nie rozumieją, dlaczego innym nie zależy na prędkości
• Niektórzy członkowie zespołu przestają czuć ownership za swój kod, dzięki “siatce bezpieczeństwa” w postaci doświadczonego reviewera. Jeżeli reviewer też przyklepał to rozwiązanie/też tego nie zauważył, no to musi być dobrze…
  • W pewnym sensie dzielą się odpowiedzialnością, co nie jest fair biorąc pod uwagę jak mało czasu reviewer ma na analizę kodu.

Kończymy z sytuacją, gdy PR Review zapewnia bardzo nieregularną jakość.

Nie dowozi jakości kodu

Kolejną ułudą jest postrzegane PR Review jako narzędzia do utrzymania jakości kodu. W praktyce często nie spełnia tej roli. Mamy w branży świadomość, że testy manualne czy automatyczne nie wyeliminują wszystkich błędów. Jednocześnie wydaje nam się, że krótkie review kodu podczas PR jest wystarczającą inwestycją w jakość.

Recenzenci często skupiają się na drobnych, powierzchownych problemach zamiast na głębokich, fundamentalnych aspektach kodu. Największą wartość mają zmiany dotyczące architektury i struktury kodu, które znajdują się na dole piramidy Code Review

Te zmiany są jednak najtrudniejsze do wykrycia (często brakuje nam czasu i kontekstu) oraz naprawy podczas przeglądu PR.

Co wpędza nas w…

Wydłużanie Lead Time

Ostatnio popularyzowany framework DevEx mocno podkreśla znaczenie dwóch filarów produktywności:

• Krótkich pętli zwrotnych dostarczających informacji jak nam idzie.
• Uczucia flow, które możemy dla uproszczenia przyjąć jako skupienie.

Poleganie na review podczas PR wprowadza wąskie gardła w obu tych obszarach - ponieważ wprowadzamy rozpraszacze dla reszty zespołu w losowych momentach (przerywając ich flow) oraz otrzymujemy pętlę zwrotną stosunkowo wolno (kwestia godzin, zamiast sekund).

W 2024 roku, kiedy wszyscy mówią o GenAI, możemy sobie wyobrazić, że wolumen produkowanego kodu na kontrybutora będzie rosnąć, co oznacza jeszcze większe problemy ze skalowaniem się tego procesu.

Ostatecznie tworzymy znaczne kolejki w zespole - jak Radek opisał w artykule  Dlaczego tak wolno dowozimy.

Brak kontekstu i przeładowanie

Recenzent nie widzi szerszego kontekstu.

Pliki, które nie zostały zmienione, nie są widoczne, więc wymagany jest większy nakład pracy by zobaczyć kod, na który może mieć to wpływ (np. miejsca wywołujące zmienioną klasę).

Jeżeli pracujemy w projektach, które posiadają oddzielne repozytoria i jeden zespół dotyka ich wszystkich (np. osobne repo na frontend, bibliotekę komponentów, backend, testy e2e, konfigurację itd.), może być konieczne odnoszenie się do poprzednich lub równoległych PR, aby dostatecznie dobrze zrozumieć kontekst wprowadzanej zmiany.

Sytuacja robi się jeszcze gorsza, jeżeli:

• review trwa długo lub PR oddalone są w czasie,
• reviewer pracuje nad innym zadaniem,
• jeżeli recenzenci mają małą znajomość wyżej wymienionych repozytoriów, ale konieczny jest approval z uwagi na zdefiniowany proces.

Wtedy musimy wczytać większy kontekst, aby faktycznie przeprowadzić jakościowe review.

Iluzja wymiany wiedzy

Na stronie GitHub PR Review zostały opisane jako proces, który wspiera wymianę wiedzy. Twierdzimy jednak coś innego – dają one iluzję wymiany wiedzy.

Komentarze dotyczą zmian, a nie wiedzy wymaganej do wprowadzenia tych zmian. Przez co albo:

• Nie zdobędziemy tej wiedzy podczas PR Review.
• Dopytamy o to w komentarzach, co da płytką wymianę wiedzy.

Prowadzi to do sytuacji, gdzie reviewer spoza zespołu może blokować zmianę (i zespół) na ostatniej prostej. Nie wynika to ze złych chęci tylko braku kontekstu – czy jest to prototyp zawężony do jednego klienta, a może fundament dla prac kolejnych zespołów?

Liderzy czy ownerzy repozytoriów/obszarów w kodzie często oczekują prawa approvala aby trzymać rękę na pulsie i wiedzieć co się dzieje. Jednak etap PR review jest zdecydowanie zbyt późnym w SDLC, aby drastycznie proponować zmianę kierunku rozwoju. Przez co zmiany są wprowadzane przy minimalnej wymianie wiedzy.

Przedwczesna optymalizacja

W sieci możemy znaleźć wiele artykułów pouczających programistów, aby podczas Review akceptowali inne rozwiązania problemu niż ich preferowane, jeżeli jest to tylko kwestia opinii.

W praktyce bardzo ciężko jest pozbyć się biasów i uniknąć takich komentarzy.

Uważamy jednak, że ten problem nasili się podczas PR Review:

1. PR Review nie zapewnia wymiany wiedzy – to sprawia, że nie rozumiejąc powodów wykonania zmiany będziemy ją optymalizowali pod inne kryteria.
2. PR Review jest bardzo widoczne – to sprawia, że będziemy chcieli przeprowadzić „rozwijające” zmiany

Reviewerzy z większym doświadczeniem, mają tendencję do proponowania bardziej złożonych podejść. Szczególnie w zespołach, gdzie kultura techniczna jest mocno rozwinięta.

To skutkuje kosztownymi zmianami w implementacji, które nie zawsze przynoszą oczekiwane rezultaty, a czasami wręcz łamią zasady KISS i YAGNI.

Niestety, na tym etapie jest często tak wcześnie, że jeszcze nie mamy pewności jaki wzorzec czy model abstrakcji będzie znacząco lepszy od prostszych do utrzymania alternatyw. W rezultacie zaczynamy optymalizować i inwestować w nasze wyobrażenie przyszłości, które może się nie spełnić.

Utrudnienie wprowadzania małych usprawnień

Jeśli każda zmiana musi przejść przez ten sam ciężki proces to wprowadzanie małych, inkrementalnych zmian jest utrudnione. Wobec czego łatwiej jest:

• Wprowadzać duże zmiany raz a dobrze – rośnie wielkość mergowanego kodu (co zwiększa Lead Time), a im większa zmiana podczas PR review tym bardziej nasz cognitive load jest wysycony, przez co review staje się płytsze
• Nie wprowadzadzać poprawek po zmergowaniu największej zmiany - ucieka nam cała praca po wdrożeniu.

Trudno w takim środowisku stosować zasadę scoutów

“Leave Things BETTER than you found them.” ~ Robert Baden Powell

Raczej budujemy środowisko, które odstrasza programistów od aplikowania jej.

Rozmiar Review wzrasta

Po zaakceptowaniu powyższych punktów, większość PR Review będzie dążyła do wprowadzania coraz większych zmian. A to wpływa na opisaną już jakość.

Biorąc na tapet artykuł From Async Code Reviews to Co-Creation Patterns z InfoQ:

A correlation between change size and review quality is acknowledged by Google and developers are strongly encouraged to make small, incremental changes.

Tak duże zmiany odstraszają reviewerów - albo przejdą przez proces bez żadnego sprawdzenia, albo utkną tam na wiele dni. Jeżeli wystarczy nam sił na to drugie, to dochodzi tutaj również problem integracji zmian, ponieważ PR wiszący długo zaczyna odstawać od głównego brancha - pojawiają się konflikty i zablokowani programiści, którzy na zmianę czekają.

Narzędzia PR powodują relacje ping-pong

Nie komunikujemy się ze sobą, przerzucamy PR do kolegi.

Utrudnia to budowanie relacji w zespole. Budowanie kultury pracy zespołowej (szczególnie w zdalnych zespołach) jest znacznie trudniejsze, gdy cała komunikacja opiera się na komentarzach w GitHub. To promuje relację siły – osoba zatwierdzająca ma władzę.

Zwłaszcza w zespołach asynchronicznych, konflikty, które na słuchawce można by rozwiązać w kilkanaście minut potrafią ciągnąć się dniami poprzez komentarze.

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

Podsumowanie

Kiedy rozpoczynaliśmy ten artykuł, to miał być o wiele krótszy. Ale liczba problemów i powodów była dla nas zaskakująca. Dlatego postaraliśmy nie iść na łatwiznę i zebrać je wszystkie razem.

Daj znać w komentarzach, czy te również odczuwasz te problemy 😊

📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

P.S. Co myślisz o tym newsletterze? Odpisz :)