Czy potrzebujemy review do pull request’ów?

Natrafiłem na ciekawy blog post napisany przez Jessica Kerr na temat pull request’ów. Znalazłem tam kilka ciekawych tez i postanowiliśmy nagrać odcinek.

Rozmawiamy:

• dlaczego nikt nie chce robić review do pull request’ów?
• jak wygląda dobrze zrobione review?
• czy warto inwestować tyle czas na sprawdzenie każdej zmiany?
• czy pair programming / mob programming jest alternatywą?
• jakie widzimy problemy z mob programming?

Zapraszam do wysłuchania podcast. Rozmawiamy mocno subiektywnie na bazie naszych doświadczeń.

Transkrypt:

Marek Piechut

Witam Panie Bartku.

Bartek Witczak

Witam Panie Marku.

Marek Piechut

Jaki mamy temat na dzisiaj?

Bartek Witczak

Na dzisiaj? Słuchaj, zainspirowany blog postem Jessicy Kerr na temat pull request’ów. Chciałem żebyśmy troszkę na ten temat porozmawiali. Ja przejrzałem ten artykuł, a można powiedzieć, że go dogłębnie przeczytałem. Notowałem sobie tutaj kilka tematów i chciałem, żebyśmy po prostu o tym porozmawiali i odnieśli się do tego jak to wygląda u nas i co my o tym myślimy.

Marek Piechut

Widziałem właśnie, że tam bardzo, bardzo zażartą polemikę na Twitterze prowadziłeś w tym temacie.

Bartek Witczak

No zgadza się, zgadza się. Generalnie cały artykuł, mogę powiedzieć, że jest dosyć ciekawy. W związku z tym, że ma kilka ciekawych tez. Nie podoba mi się rozwiązanie, ale no to dojdziemy do wszystkiego i porozmawiamy. No dobra, sam wydźwięk artykułu jest taki, że nikt nie chce robić rewiews’ów pull requestów, czyli te pull requesty sobie czekają.

Marek Piechut

Z tym się zgodzę.

Bartek Witczak

Tak, robimy commit, wrzucamy jakiegoś tam GitHub-a, GitLab-a czy innego BitBucket-a nasz kod i prosimy kogoś z teamu, żeby zrobił review naszego kodu. Przeważnie kończy się tak, że albo musimy kilka razy powiedzieć, albo wykorzystujemy jeszcze jakieś wtyczki do slacka, które po prostu 500 razy przypominają o tym, że jest review do zrobienia i żeby ktoś to zrobił. No i dopóki prawdopodobnie kilka razy nie poprosimy kogoś ładnie, żeby zrobił to review, bo to czeka i nie możemy tego zakończyć, to tak sobie te reviewsy leżą. Z mojego doświadczenia to jest taka sytuacja, że wszyscy kończą pracę i dopiero kiedy nikt nie ma otwartego zadania, to są ogarnięte te reviewsy.

Marek Piechut

No to ja się częściowo z tym zgodzę, a częściowo się z tym nie zgodzę, bo doświadczałem też takich rzeczy, w których to, takich projektów, w których to zdecydowanie lepiej działało. Powiedziałbym, że to dosyć mocno zależy od kultury i organizacji pracy. To znaczy masz rację z tym, że jeżeli zostawi się, to tak samo sobie, to prawdopodobnie tak się skończy, a szczególnie jeżeli będzie się rozliczać ludzi z rzeczy dowiezionych. A każesz im zużywać, marnować swój czas na przeglądanie cudzego kodu, za które to ten ktoś będzie miał policzone swoje punkty, wiesz, punkty premiowe, to to szczególnie nie działa. Ale, wiesz co? Zdarzały mi się takie przypadki, kiedy działało i to było, w sensie na pewno musisz mieć pull request. W sensie wtedy jako tam reviewsy jako część procesu wytwarzania softu. Tak, czyli musisz normalnie planować na nie czas, bo to musi być normalna część pracy. Jeżeli ja pracowałem wtedy w sprintach, w projekcie i po prostu to była część pracy w sprincie i to nie była jakaś część zostawiona na koniec sprintu czy coś w tym stylu, tylko po prostu w momencie kiedy skończyłeś task’a, to musiałeś zrobić review następnego task’a, jeżeli był w kolejce. Te rzeczy w miarę działały, tym bardziej, że strony też menedżerskie działało to także nigdy nie było z tym problemów takich, że za dużo czasu na to schodzi, czy coś takiego, tylko to był czas, który dało się normalnie wyciąć z pracy.

Bartek Witczak

No dobra, bo teraz, jeżeli w ogóle mówimy o pull requestach, no to jak zastanawiałem się jak wygląda dobre review, no to rzeczywiście wymaga to i sporo czasu i sporo takiej pracy umysłowej. Pobieramy kod, odpalamy go lokalnie, odpalamy testy, patrzymy tak naprawdę jak i co to w ogóle był za task. Tak, musimy zrozumieć cały kontekst. Najlepiej byłoby, gdybyśmy sami przemyśleli jak to należy wykonać tak żeby zderzyć tą naszą implementację w głowie z tym co zostanie wykonane.

Marek Piechut

Zgadzam się z Tobą, że najtrudniejsza część tej roboty to jest ta koncepcyjna. Ty musisz wgryźć się w tę domenę tego problemu, który ktoś rozwiązywał, bo taki review kodu, który jest jest taki typowo techniczny, czyli taki, który z reguły ludzie robią pod przymusem, no to on niewiele wnosi. To są reviewsy w stylu “no weź tego fora zmień na coś tam”, nie,” a tu, a tutaj za dużo ifów masz”. I to jest takie coś, co nawet automatyczne narzędzia ci coś takiego zrobią i to nie jest review. Z tym, że też jestem w stanie sobie wyobrazić projekty techniczne review ma dużo sensu. To są projekty mocno techniczne i wtedy jak masz ludzi mocno doświadczonych w projekcie mocno technicznym, czyli piszesz full request, wrzucasz do Postgressa powiedzmy, łatę do Postgressa, no to ci goście, którzy tam pracują ileś tam lat, to oni spojrzą w ten kod i powiedzą nie, nie stary, to zwolni wszystkie query 4 razy, bo ja już to widziałem 700 razy. Także tam są duże szanse na taki wyrwany z kontekstu codereview, który będzie miał dużo sensu, ale w biznesowym sofcie pewnie nie bardzo, bo musisz się w ten biznesowy problem wgryźć.

Bartek Witczak

No właśnie, bo tam też jeden z tych punktów w tym artykule jest taki, że jakby robienie dobrego review wymaga praktycznie wszystkich elementów z wykonania danego tam task’a czy ficzera, poza, tym powiedzmy, że najciekawszym pisaniem kodu tak naprawdę cały cały kontekst musisz odtworzyć wszystko musisz zrozumieć, zaplanować, abyś to zrobił, a nie masz tego elementu, że możesz sobie usiąść do…

Marek Piechut

Nie budujesz.

Bartek Witczak

…pisania, tak i budowania. I jest jeszcze jedna rzecz, pomyślałem sobie, która też rzeczywiście jest słaba w takim podejściu, takich mocnych review, bo teraz wyobraż sobie sytuację, że ten zespół, w którym pracujesz, jest, powiedzmy, że mocno zróżnicowany-poziom osób. I teraz, jeżeli nie ma tej fazy takiej wstępnej, gdzie planujemy, jak to zostanie wykonane, to zdarzają się często sytuacje, że dostajesz pull request do przejrzenia, który totalnie jest jakby nie powiem, że zmarnowanym czasem, ale takim wiesz, po prostu patrzysz na ten kod, zastanawiasz się jak to miałoby wyglądać, widzisz, że jest zupełnie inaczej niż w ogóle sobie to wyobrażałeś.

Marek Piechut

Ale to też nie jest tak. Ja nie wiem, czy to jest zmarnowany do końca czas, czy kod, czy coś takiego, bo z tego co rozumiem, to idziesz do tego motywu, że masz zróżnicowany team, masz juniorów i ktoś musi tych juniorów przeglądać kod, bo inaczej wszystko eksploduje. I tam są duże szanse, że będziesz miał po tym review wnioski w stylu “Jezus Maria, lepiej to wszystko wywalić”, ale to jest proces wdrażania juniorów w projekt, nie?

Bartek Witczak

No dobra, a nie wydaje Ci się, że lepszym rozwiązaniem byłoby podejście, żeby zrobić albo taką sesję, powiedzmy technicznego planowania, albo pair-programming z taką osobą.

Marek Piechut

W sesje technicznego planowania to ja mam dosyć sceptyczne podejście. Jeżeli tak naprawdę masz problem mocno rozgryziony, to tak, to pewnie jesteś w stanie jakby up-front porysować te pudełka i powiedzieć tak, że tu to będzie takie pudełko, to spróbujemy tak, tu tak, to tak. Mnie się wydaje, że w większości przypadków będzie tak, że usiądziesz do kodu i te Twoje pudełka się rozsypią w przeciągu godziny. Nie, że Ty zaczniesz spinać rzeczy i się okaże, że one nie pasują w ogóle jednak do tego wszystkiego i tak skończy się jakby na designowaniu w trakcie wykonywania. No, a pair-programming pewnie byłby spoko, tylko on nie zawsze jest możliwy i nie zawsze jest fajny też, nie? Bo ja też patrzę na ten aspekt psychologiczny tego, że nie każdy się lubi pair-programować, a już w ogóle nie każdy się lubi pair-programować na pełen etat.

Bartek Witczak

To jest jedna rzecz. A druga rzecz jest taka, że to jest bardzo energochłonne. Więc jakby kończysz z taką sytuacją, albo możesz skończyć z taką sytuacją, że tak naprawdę w ciągu całego dnia jesteś w stanie 2/3 godziny zrobić pair-programmingu i to jest praktycznie koniec dnia. Okay, ale może byłoby to wydajne, trudno powiedzieć. Wrócę teraz do takiej jeszcze jednej kwestii, która tam została poruszona, a mianowicie tego, że pull requesty to jest coś, co stało się bardzo popularne w momencie, kiedy zaczęliśmy mocno korzystać z GitHuba i z projektów open-source’owych. I teraz my ten styl pracy nad tymi projektami, które mamy open-source’owe, gdzie pracujemy, w założeniu, z ludźmi, których nie do końca znamy, przełożyliśmy na współpracę w teamie, gdzie generalnie dosyć dobrze znamy siebie nawzajem, dosyć dobrze znamy swoje skille techniczne, wiemy jak ten kod mniej więcej z naszej strony będzie wyglądał. I teraz jakby jest taka teza, że nie do końca ten styl wiesz, tego GitHuba opensource’owego pasuje do takiej pracy w teamach. Co o tym myślisz?

Marek Piechut

To znaczy wiesz co, ja się zastanawiam nad tym jak byśmy cofnęli się jeszcze trochę w czasie wcześniej, bo pull request, jakieś tam code review itd. te rzeczy istniały zanim był GitHub z tym całym modelem i z tym całym modelem z tym socjalistycznym kodowaniem. I ten model wyglądał troszkę inaczej, trochę czemu innemu służył. To jest taki bardziej model w stylu jądro Linuksa. Czyli jest ktoś, kto bardzo dobrze zna jakiś moduł systemu i on, jeżeli Ty nie jesteś jego zaufanym poplecznikiem, no to on będzie przeglądał Twój kod, zanim zostanie wmeargeowany tak? Czy tak jak jest w Linuxie że ty po prostu mailem prześlesz patch-bombę czy coś takiego to ktoś go przejrzy. Jak Ty jesteś doświadczonym członkiem zespołu to pewnie nikt go nie przegląda albo przegląda go 3 minutki tak sobie ciach, ciach, ciach. I to było troszkę coś innego, bo z tego co rozumiem Ty teraz jako code review i jako ten cały model, to bardziej mówisz o tym modelu, który teraz się spotyka najczęściej, czyli modelu w stylu “niech ktoś przejrzy ten kod” i kończymy z reviewowaniem juniorów przeglądających kod seniorów, tak?

Bartek Witczak

Trochę tak, ale wiesz co, mnie chodzi bardziej nawet o taką sytuację, gdzie w tym modelu, tych pull requestów, o których Ty mówisz, to ta współpraca taka mocno asynchroniczna jest bardzo wskazana i ona, można powiedzieć, że jest zupełnie nie problematyczna. To, że nowa wersja jądra wyjdzie tydzień później czy pięć dni później to niewiele zmienia.

Marek Piechut

Znaczy te rzeczy by nie weszły, bo to jest taki proces, że nie wchodzą rzeczy, które nie są gotowe.

Bartek Witczak

Bardzo demokratycznie i po prostu jak nie jest klepnięte, to nic się nie dzieje.

Marek Piechut

Jest ucięte toporem i dowidzenia.

Bartek Witczak

Dokładnie, ale wiesz i teraz ten model pasuje bardzo fajnie, bo tam jest taka pełna asynchroniczność i to jakby nikomu nie przeszkadza. A teraz nagle masz ten cały proces wrzucony w środowisko teamu, które powiedzmy, że już ma Continuous integration, Continuous delivery i po prostu musi 15 tysięcy razy dziennie deploy’ować na produkcję. Więc jeżeli to jest część Twojego procesu, to tak naprawdę jeżeli Ty każdą poprawkę, bo to jest dla mnie ważna, ważna rzecz, jeżeli każdą poprawkę chcesz przechodzić przez ten review tak naprawdę ten twój pipeline, tak, ten twój working progress, jakimś tam powiedzmy Kanban’owy staje się ogromny, bo Ty nagle będziesz miał ficzery czy bugfixy, które mogą być dostarczone w ciągu godziny, a Ty możesz skończyć z tym, że będziesz czekał dwie godziny, pół dnia czy nawet cały dzień na to, żeby ktoś Ci zrobił review.

Marek Piechut

Nie wiem, nie umiem rozwiązać Twojego problemu szczerze mówiąc, bo rozumiem, że nie jesteś w stanie. Tylko, czy są tak krytyczne rzeczy, które musisz mieć na produkcji za godzinę, bo jeżeli one są, to one prawdopodobnie i tak nie mają żadnego procesu, że to są rzeczy w trybie “niech ktoś szybko gasi ten pożar, a ty Czesiek tam podmieniaj skrypty na serwerach”, nie?

Bartek Witczak

Bo dla mnie ten artykuł właśnie był o tyle ciekawy, że on pokazuje jakby problemy, które są w tych w tych pull questach i tym procesie review. I to jest fajne. Jeżeli chodzi o rozwiązanie to nie jestem fanem, bo akurat tutaj Jessica wnioskuje o to, żeby był teraz coraz bardziej popularny mob-programming czyli 5 osób siedzi przy monitorze i patrzy jak jedna osoba sobie koduje. Czyli trochę jak taki klasyczny mem z robotnikami na torach. Tam jeden kopie, czterech patrzy i trzyma łopatę, czy on tam rzeczywiście równo kopie. I wydaje mi się, że to wogóle totalnie niszczy ludziom mózgi akurat.

Marek Piechut

Mi się ten model też nie podoba, także się zgadzam z Tobą, bo on jest o tyle kłopotliwy, że zawsze jak jest więcej niż dwie osoby to nie ma focuse’u, że dwie osoby są w stanie się skupiać na tym samym i siebie nawzajem trzymać w ryzach, nie? A jak wkładasz trzecią to ona już dostaje powiadomienie, coś tam się stało, potem przez 10 minut patrzyła na coś tam, wyskoczyła po kawę, wraca, a potem ma uwagi do rzeczy, które już zostały omówione w tym czasie co ona poszła po kawę, i jeszcze rozwala robotę tym innym.

Bartek Witczak

Dokładnie tak.

Marek Piechut

A ta reszta tam wiesz, przewija tylko instagram i wiesz, czeka sobie kiedy pójdzie do domu.

Bartek Witczak

No. Ten element mnię w ogóle bardzo rozśmieszył, bo jakby w tym artykule jest właśnie powiedziane, że pair-programming jest taki bardzo wyczerpujący i bardzo trudny i dużo energii tracisz, więc niewiele tego możesz zrobić w ciągu dnia. No i dlatego rozwiązaniem ma być mob-programming, gdzie cały team siedzi, bo wtedy zużywasz trochę mniej energii i nie musisz być tak bardzo skupiony. Jakby w ogóle według mnie to jest strzał w stopę, bo ja już to sobie po prostu wyobrażam jak tam cztery osoby siedzą i przeglądają fejsa.

Marek Piechut

No ale nie brałeś udziału w takich meeting’ach, w stylu “słuchajcie, musimy się spotkać, bo trzeba rozwiązać ten problem.” I spotykamy się, i tam jest Ryszard, który siedzi przed kompem, widzimy jego kompa. Tak, najlepiej jeszcze na call’u wszyscy są i Rysiek najbardziej w takich kryzysowych rzeczach, że tam coś nie działa i Rysiek wchodzi do jakiegoś folderu i coś tam otwiera i mówi “ta tablica routingu wygląda dobrze” i jeden się zna na routingu to patrzy a reszta “co ja tu robię?” “Wiesz co to ten routing w ogóle?” “Nie wiem, ale trzeba siedzieć to siedzę”, tak?

Bartek Witczak

Znaczy ja to w ogóle otwarcie zawsze mówię, że jeżeli meeting trwa ponad godzinę, to ja już w ogóle jestem gdzieś indziej. No nie, to jest tylko ta różnica, że ja się po prostu do tego przyznaję, a większość osób sobie po prostu siedzi, scrolluje facebooka i udaje, że jest na spotkaniu.

Marek Piechut

No i mi to też trochę przypomina ten model tego wszędobylskiego Slacka, czyli kanału pod tytułem “Wszyscy we wszechświecie” i wszyscy dostają powiadomienia o tysiącu bzdur, które ich w ogóle nie dotyczą. Oczywiście wszyscy w firmie zakładają, że ty śledzisz tego Slacka, no bo jakżeby inaczej. Czyli jak tam ktoś napisał, to znaczy zostało to ogłoszone. Wydaje mi się, że pretekst do tego wszystkiego jest taki, że my chcemy feedback od jak największej ilości ludzi, albo, że liczymy na to, że ktoś, kto by o czymś nie wiedział, to nagle o tym przeczyta i da jakiś świetny insight, którego tak to byśmy mieli nie dostać i szansa zostałaby utracona. Nie? Tylko, że nikt nie patrzy na koszt, który trzeba ponosić ciągle i który jest praktycznie pewny. Ten koszt wszystkich ludzi, którzy marnują czas jakby tym slackiem, który ich dręczy itd. I koszt tego całego zmarnowanego czasu, czy on w ogóle w jakimkolwiek stanie jest, wiesz. Ta korzyść z tego insight, który wpadnie raz kiedy i miejmy nadzieję, że to nie będzie to, które płatki są lepsze, że on spłaci ten cały koszt.

Bartek Witczak

Mhm, no i według mnie tutaj jest bardzo, bardzo podobnie. Wydaje mi się, że w ogóle review to jest taki element, który powinie dotyczyć tych kluczowych zmian, które robimy. Wydaje mi się, że naprawdę wiele rzeczy w projektach to są takie w miarę proste tematy, które trzeba ogarnąć. Niewiele jest takich złożonych funkcji, które musimy ogarnąć w kilka osób i wszyscy muszą to przejrzeć, czy ktoś musi zrobić review. Bo moją ulubioną praktyką jest to, że im większy jest team, tym oczywiście do tych reviewers’ów w pull request to wpadają tam wszyscy. Tmam nie jest wybrana jedna osoba, która ma zrobić review, tylko oczywiście wszyscy są przypisani, więc wszyscy muszą przejrzeć kod jeszcze GitHub jest ustawiony w ten sposób, że muszą dwa być aprove’y, tak? Więc po prostu co najmniej dwie osoby muszą poświęcić czas na to, żeby przejrzeć i zaakceptować czy te zmiany są możliwe, no nie? A tam się zmieniły CSS i jest border radius na 25 teraz.

Marek Piechut

Teraz wiesz jedna rzecz jest taka-czy czy dwie osoby, które są nie doświadczone w systemie zrobią lepszy review niż jedna osoba, która jest doświadczona w systemie na przykład. Tam jest, jest trochę też innych problemów w tym. Ja też nie mówię, że to jest bez sensu, bo zdarzało mi się pracować w takich sytuacjach, gdzie to miało sens. Tylko trzeba się liczyć z tym kosztem. W sensie, że krótkoterminowy będzie koszt, nie da się tego przeskoczyć, że to nie jest tak, że ludzie zrobią review w międzyczasie.

Bartek Witczak

Według mnie to jest duży koszt i ja chciałbym być w takim środowisku, gdzie te review są w miarę przemyślane. Czyli jakby jeżeli ja potrzebuję review, to ja wiem, dlaczego chcę, żeby ktoś ten kod przejrzał. Tak, jeżeli wchodzę w nowy projekt, to chcę od jakiejś osoby, która jest doświadczona w tym projekcie, żeby ona to przejrzała. Mam konkretne pytania do tego, co tam rzeczywiście może być. Ja nie chcę, żeby to były review w stylu “no dobra, no to teraz będziesz przeglądał mój każdy commit, bo potrzebny jest aprove na GitHubie”, nie?

Marek Piechut

Ja nie jestem aż tak sceptycznie nastawiony do tego, żeby wszystkie zmiany przeglądać, także nie jestem aż takim przeciwnikiem tego modelu, że wszystko co jest merge’owane jest przeglądane. Troszkę trzeba wtedy uważać, schedule’ować i troszkę trzeba uważać na to, żeby nie wrzucać też zmian niedokończonych i tak dalej, i tak dalej.

Bartek Witczak

Jasne.

Marek Piechut

To jest też duży problem. No ale wracając trochę do tego, do tego artykułu, który był zalążkiem tej dyskusji, to nie wiem, ja powiem Ci, że ten Mob-programming, dla mnie ten cały model jest straszliwie utopijny. Chciałbym go naprawdę poznać w praktyce, kogoś, kto realizował tak projekt i było świetnie.

Bartek Witczak

Ja bym chciał w ogóle poznać te osoby, które wymyśliły, że to jest dobry pomysł.

Marek Piechut

No, to, że wymyślili to mnie nie dziwi, bo ludzie mają różne pomysły, ale.

Bartek Witczak

Nie no dobra, ale ludzie mogą mieć pomysły, wiesz, w fazie koncepcyjnej i jakąś walidację, po prostu koncepcję, to musi przejść.

Marek Piechut

Jakby mi się zdarzało widzieć projekty robione skrajnie w odwrotny sposób, z wielkim faszystą na górze, który śmigał batem i mówił “Ty teraz będziesz pisał tutaj ten kod, a jak ci nie pasuje, to weź się wyprowadź”.

Bartek Witczak

To ja preferuję taki styl.

Marek Piechut

I ten styl się sprawdzał wielokrotnie. Tak, i pracowałem w bardziej liberalnych środowiskach, ale te wszystkie akcje w stylu spotkajmy się teraz w 10 osób, bo musimy naprawić ten serwis, bo nikt nie wie jak go zrobić, to zawsze był straszny waist, w sensie, że to nigdy się nie sprawdzało.

Bartek Witczak

A nie masz wrażenia, że to jest jakby brak chęci wzięcia odpowiedzialności i to jest taka wtedy rozmyta odpowiedzialność, bo wszyscy programujemy, jak ktoś coś popsuje, no to popsuliśmy wszyscy, dlatego że wszyscy patrzyli na ten kod.

Marek Piechut

To jest też na następnym poziomie, jakby ten problem z odpowiedzialnością mi się wydaje, bo jedna rzecz z odpowiedzialnością jest taka, że wtedy nikt nie bierze odpowiedzialności i wszyscy są zadowoleni z siebie, bo robimy sobie kod i w razie czego to na nikogo nie będzie. A druga część odpowiedzialności jest też taka, że nie potrzebujesz zarządzać tymi rzeczami, tak? Nie masz odpowiedzialności, że ktoś robi jakieś rzeczy, kto nie jest do tego np. przygotowany, albo ktoś robi jakieś rzeczy, czy ktoś ich nie robi nawet, tak? To jest jeszcze gorsza rzecz. I też nie ma tej odpowiedzialności. Więc wszyscy na koniec możemy się poklepać po plecach, a nic nie powstało, Nie? I to jest tak, że się zgadzam z tym, że tu jest duży, duży taki przejaw tego, bo im większa ilość osób za coś odpowiada, tym mniejsza ilość osób za coś odpowiada.

Bartek Witczak

No dokładnie. I też wydaje mi się, że trochę przesadzony jest ten ciężar odpowiedzialności, która ma niby być brana, no nie? Na pewno są jakieś systemy, które są bardzo istotne dla życia świata, jakieś nie wiem, systemy bankowe czy jakieś medyczne, gdzie rzeczywiście naprawdę komuś coś może stać się złego, jak tam będą jakieś totalne błędy. Ale wydaje mi się, że jakby większość systemów, która jest robiona, no to jeżeli na slacku nie wyskoczy nam powiadomienie, to raczej nic złego się nie stanie.

Marek Piechut

To znaczy ja też nie chcę tak mówić, że jestem przeciwnikiem takich rzeczy w stylu-piszemy jakiś kawałek kodu i weźmiemy dwóch speców od baz danych czy od security czy od czegoś I niech oni nam powiedzą czy to ma ręce i nogi czy nie i siedzimy np. w czwórkę i coś tam robimy czy coś takiego.

Bartek Witczak

Ale to jest zupełnie inny case.

Marek Piechut

Tylko jest inny case.

Bartek Witczak

To jest dokładnie ten case, o którym ja mówiłem wcześniej, że bardzo świadomie chcesz review.

Marek Piechut

To nie jest nawet review, tylko właśnie taki mob-programming. Tylko że on jest, on jest zadaniowy. Nie? Że to jest mob-programming dlatego, że brakuje nam kompetencji i szukamy kogoś, kto ma dużo większe kompetencje i nam pomoże. I przy okazji my trochę przejmiemy tych kompetencji.

Bartek Witczak

I tak samo jest uważam jeżeli chodzi o pair-programming. Nowa osoba wchodzi do teamu, jeżeli będzie jakiś tam pair-programming to na pewno będzie dużo szybciej wdrożona w system. Zupełnie inaczej będzie to wyglądało niż kiedy mamy 3 osoby, które od samego początku siedzą w projekcie i one teraz wszystkie razem by miały programować cały czas.

Marek Piechut

Znaczy też mi się wydaje, że ad-hoc pair-programming też jest fajny, że to się dobrze sprawdza jak są jakieś rzeczy, które chcesz z kimś zrobić, żeby ci patrzył przez ramię.

Bartek Witczak

Mi Marek, wiesz, zawsze chodzi o takie skrajności, Nie? Bo ja zakładam, że zarówno pair-programming, jak i ten mob-programming, czy takie programowanie solo to na wszystko jest miejsce w projekcie, no nie? A my już znamy osoby, które pracują w takich środowiskach, gdzie jakby non stop pracuje się cały dzień, wszyscy programują razem jeden kawałek kodu.

Marek Piechut

Wiesz, to jest ten problem, że to się wszystko zaczyna zamieniać w religię, nie, że nie patrzymy na to o co nam chodzi i po co to robimy, tylko “nie bo tak wujek Sam z Ameryki powiedział, że tak się robi najlepiej software”.

Bartek Witczak

Więc podsumowując ja uważam, że na wszystko jest miejsce i na pair-programming i na mob-programming nawet i jakieś duże ilości review, ale to w odpowiednich miejscach i nie zawsze i nie do wszystkiego.

Marek Piechut

Tak, ja nie jestem aż tak dużym przeciwnikiem do oczekiwania, że każdy kawałek kodu będzie przez kogoś obejrzany. Też nie oczekiwałbym tego, że to po prostu będzie panaceum na wszystko i teraz już nie będzie bugów, i jakość będzie kosmiczna tak, ale często jest tak, że druga para oczu gdzieś tam coś tam złapie. Tylko, tylko trzeba też takie coś wytworzyć, że mamy na to czas i że naprawdę robimy to review i trzeba się nauczyć przyjmować feedback i to też może być dosyć trudne.

Bartek Witczak

A to jest zupełnie inna bajka.

Marek Piechut

Pamiętam, że to dla mnie było bardzo trudne na początku i trzeba się tego nauczyć. No to boli, ale to jest niezbędne do tego, żeby review miał sens. Nie możesz się bać tego, że ktoś się obrazi, bo Ty mu napiszesz, że ten kod się nie nadaje.

Bartek Witczak

Zdecydowanie, zdecydowanie.

Marek Piechut

Mob-programming. Jestem za. Tylko jeszcze musi być browarek i nieskończony budżet. Wtedy jestem za, możemy się mob-programować ile wlezie.

Bartek Witczak

A to są takie projekty. Takie projekty też dla pana znajdziemy.