Dev, który olewa code-review

Mam taki problem, że klient zrekrutował sobie własnego deva do projektu, który im robimy.
Natomiast ów człowiek jest mega-oporny na jakiekolwiek uwagi, code-review.

Ogólnie zamiast spojrzeć szerzej na to, co modyfikuje i poświęcić trochę czasu żeby zrobić coś bez długu technicznego - kodzi gdzieś na pałę w sumie mając gdzieś kto miał jaki zamysł.
Ostatnio wygląda to tak, że dostaję same bug-tickety po tym jak gość coś rozsypał.

W review jestem raczej przyzwyczajony do tego, że wszyscy dotąd ludzie biorą to na klatę w ramach różnych skrzywień masochistycznych i dążeń do perfekcji (czasami nawet w trosce o to, nad czym pracują), a jeżeli nie - to przynajmniej mają na to dobry argument.
Natomiast typ potrafi powiedzieć nie bo nie, bo tego nie było w tasku (jeżeli chodzi o jakiś lekki refactor albo sprzątanie po sobie), co pozostawia mnie w sumie bez słów. Klient go lubi, podejrzewam że po prostu bierze bardzo mało kasy więc rozchodzi się po kościach. Dużo by wymieniać, można sobie dopowiedzieć jakieś sytuacje - w sumie wszystko przerobiłem. Już mi się nie chce sprawdzać jego rzeczy.

Jak z tym walczyć, co robić?

Dodać testy, wtedy przynajmniej nie popsuje za dużo

Eskaluj to do klienta i raportuj każdy ticket, który został stworzony przez wyczyny artysty.
Jak masz jakieś opory moralne typu "bo to nieładnie tak donosić" to przypomnij sobie, że to jest dev od klienta, który nie ma oporów przed dorzuceniem wam pracy przez własną niedbałość.

clonazepam napisał(a):

Jak z tym walczyć, co robić?

Nie walczyć, bo to niczego nie da. Prościej zmienić projekt.

Jak z tym walczyć, co robić?

1. Nie można zrobić merge brancha bez approve
2. Jak w branchu jest g**no to nie dajesz approva aż nie poprawi
3. Bugi do jego kodu przepisujesz na niego
4. Profit!

Ewentualnie walisz mu luja ogłuszacza i kołowrotek za każdą pyskówkę w stylu nie bo nie.

Jak jest mały zespół, to wymóg "bez approve nie pójdzie dalej" może się nie udać.
Ale pomysł z tym, że bugi, które on wprowadził przypisywać do niego to bardzo dobry pomysł. Możes powiedzieć tak: on to pisał więc zna kod i pójdzie mu dużo szybciej naprawienie tego.

clonazepam napisał(a):

Mam taki problem, że klient zrekrutował sobie własnego deva do projektu, który im robimy.

Natomiast ów człowiek jest mega-oporny na jakiekolwiek uwagi, code-review.
Klient go lubi, podejrzewam że po prostu bierze bardzo mało kasy więc rozchodzi się po kościach.

Może klient powinien wiedzieć ile kosztuje wychowywanie jego człowieka? Bo w tej chwili klient nie widzi wszystkich kosztów?
Jak to nie zadziała to pomysł @Shalom a jak i on nie zadziała to pomysł @somekind (to zawsze jest ostatecznie dobry pomysł, zwłaszcza biorąc pod uwagę że stawki ostatnio wzrosły)

Ogólnie zamiast spojrzeć szerzej na to, co modyfikuje i poświęcić trochę czasu żeby zrobić coś bez długu technicznego - kodzi gdzieś na pałę w sumie mając gdzieś kto miał jaki zamysł.

Czy gość jest juniorem czy seniorem?
Jak jest seniorem, to należałoby zwolnić takiego seniora, jak jest juniorem to jeszcze można by go jakoś wyedukować.

dostaję same bug-tickety po tym jak gość coś rozsypał.

Czyli w waszym projekcie jest za mało testów, skoro można coś "rozsypać".
Poróbcie se testy i dajcie wymóg (wymuszany z automatu), że muszą przechodzić, zanim coś będzie zmerdżowane. Gość może pisać słaby kod, ale to nie znaczy, że wasz zespół/projekt jest zorganizowany dobrze.

Natomiast typ potrafi powiedzieć nie bo nie, bo tego nie było w tasku (jeżeli chodzi o jakiś lekki refactor albo sprzątanie po sobie)

To może wtedy należałoby zrobić osobnego taska. Z drugiej strony "lekkie refactory" to nawet nie powinny mieć osobnego taska - nad taskami czuwa zwykle menedżment, a menedżment nie powinien się wtrącać do tego, czy programista poświęcił dodatkowe pół godziny na refaktor istniejącego kodu (bo dla niektórych menagierów takie zachowania nie mają "wartości biznesowej"... ).

A jak wygląda struktura w tym projekcie? Kto rozdziela i odbiera pracę? Jest jakiś poganiacz tego wszystkiego?

Jeśli taka osoba jest dorzucona do projektu przez klienta, to często jest dosyć ciężki orzech do zgryzienia.

Zakładam, że wyczerpaliście już dobrą wolę do naprostowania gościa - sam miałem podobną sytuację rok temu (dev z wieloletnim doświadczeniem, nie potrafił pracować w teamie bo wcześniej robił zawsze sam, ogólnie konfliktowość i "nie bo nie", wybiórcze poprawianie po CR - to doprowadzało mnie do białej gorączki, nie trzymanie konwencji, braki technologiczne itp itd ogólnie był słaby i nie przeszedł rekrutacji u nas, ale później poszedł do klienta i tam go wzięli) i skończyło się tak, że atmosfera wyeskalowała się do tego stopnia, że gościo się zwolnił + zrobił z siebie ofiarę że to przez nas i nikt go nie lubił.

My próbowaliśmy z tym walczyć w ten sposób (po długich próbach podejścia z dobrą wolą, ale ile można) , że:

• jego fackupy przypisujemy do niego bo "zna kod który napisał"
• eskalowanie na daily, że coś wisi w CR do poprawy - wystarczy wspomnieć żeby wszyscy usłyszeli - i prosicie o poprawki bo nie można tego puścić w tej postaci
• informowanie team leada / managera o sytuacji - mimo tego, że może wam się wydawać to oczywiste, trzeba o tym informować już teraz żeby w razie czego mieć zebrany bufor że problemy z gościem są od dawna
• pm powinien informować klienta - w sensie jakieś review performance i info zwrotne że ta osoba robi więcej szkody niż pożytku (a uwierz mi, performance będzie wyglądać słabo jak nie będziecie mu przepuszczać commitów bez poprawek z CR i będą wisieć aż je poprawi - wtedy pewnie będzie skamlenie że nie chcecie mu puścić, a wy powinniście odbić piłeczkę że czekacie aż zrobi poprawki)

U mnie to tyczyło się pracy w zespole, więc większa ilość osób. Przeskaluj sobie to do tego jak u Was wygląda organizacja.

Teraz to już trochę po ptakach, dyscyplinę trzeba trzymać od początku:

• Statyczna analiza kodu na każdym PR, blokuje PR łamiący reguły
• Co najmniej 1 approve na PR, brak approva blokuje
• CODEOWNERS na niektórych folderach, brak aprova Codeownera blokuje PR
• ArchUnit (to dla Javowców)

Teraz jak wprowadzisz taką regułę to może być odebrane jako atak.

"Klient go lubi", no to sprawa przegrana, bo klient płaci za rozwiązania a nie za problemy. Musisz wybadać czy to jest jeden z ludzi którzy mają po was przejąć projekt i go utrzymywać, jeżeli tak to niestety waszym obowiązkiem jest zapoznanie go z systemem, czyli nie można za bardzo dawać mu zadań z pobocza. Sprawa jest delikatna, radzę pogadać z kilkoma innymi osobami z twojej firmy zanim podejmiesz jakieś działania.

@UglyMan: My jesteśmy tylko wyleasowani, chcą mieć po swojej stronie docelowo ekipę która im to będzie dalej rozwijać. My ew. do bardzo ważnych tematów. Teraz wszystko leci po ich stronie jeżeli chodzi o zarządzanie projektem, ale jeżeli chodzi o eskalowanie do ludzi ala PM to źle to odbierają - że krytykujemy im pracownika.

Ja bym próbował eskalować i przepuszczać wszystko przez PM z waszej firmy (bo skoro jesteście tam wyleasowani to macie kogoś takiego?). PM klienta mogą odnosić się do tego wrogo, ale to już nie wasz problem. Ostatecznie, jak wspomniano już w innych komentarzach - trzymaj rękę na pulsie i jakbyś nie mógł tego wytrzymać to po prostu zmień projekt, bo jeżeli wasza firma ma wywalone na wasze problemy u klienta to też nie powinniście mieć jakiegoś dziwnego poczucia lojalności.

clonazepam napisał(a):

@UglyMan: ale jeżeli chodzi o eskalowanie do ludzi ala PM to źle to odbierają - że krytykujemy im pracownika.

A jesteś o tym przekonany czy tylko masz takie odczucie?
Ja bym eskalował problem do PM przy każdej okazji problem polega tylko na tym, że o takich rzeczach powinien decydować jakiś TL, CTO czy inny człowiek techniczny odpowiedzialny za projekt. Tak to pracujesz od 8 do 16 robisz wszystko, co jest w twojej mocy, żeby dowieść projekt. Jako outsource it zaraz wylądujesz w innym projekcie. Ewentualnie jak nie chcesz przykładać ręki do tego to pogadaj z przełożonymi o zmianie projektu, tudzież zmień firmę.
Tak naprawdę nie ma się za bardzo przejmować rzeczami, na które nie mamy wpływu.

PM to źle to odbierają - że krytykujemy im pracownika.

Nie krytykujcie pracownika tylko jego pracę ;) Zróbcie tak zeby było widać że gość robi słabą jakość

Ktoś te jego wysrywy musi approvalować, tak jak @Shalom wspomniał. Dopóki dostarcza g**no kod to nie ma approva i tyle. Wszystko warto dokumentować, żeby mieć argumentacje w przypadku gdy ten ananasek zacznie się skarżyć i płakać - Zwyczajnie powiedzieć, że człowiek szkodzi. Jeśli typ nie potrafi przyjąć konstruktywnej krytyki na klatę to trzeba go zwalczać na wszystkie możliwe sposoby (Może sam zrezygnuje? :) ) a jak to nie pomoże to się po prostu zawinąć i nie kopać z koniem.

Miałem całkiem niedawno podobny problem.
Nie dość, że gość niewiele umiał to oprócz tego był bardzo odporny na wiedzę a jego ego sięgało wyżej niż Mount Everest.
Skończyło się tym, że porozmawiałem kilka razy z PM po stronie klienta i przesunęli go gdzieś indziej.
Ostatecznie i tak zmieniłem projekt.

Przede wszystkim nie bójcie się o tym mówić głośno i każdemu, skonfigurujcie sobie odpowiednio pull requesty i merge requsty i przypisujcie do niego wszystkie bugi które mają przyczynę w tym co dostarczał - tak jak pisali już inni.

Jeśli klient to źle widzi to zastanówcie się, czy chcecie dla niego pracować - ja bym nie chciał

W sumie dopóki biznesowo się spina, a system nie leży trzeci dzień to niestety nikogo nie interesuje czy kod jest wysokiej jakości. Nic nie zrobisz.

@kate87
Oczywiście, że interesuje.
Wystarczy tylko zobrazować ile roboczogodzin tzn pieniażków traca przez takiego ancymona, to zaraz zaskoczy.

Można pogadać z delikwentem w pojedynkę. Jeśli to nie pomoże, to dogadać się z zespołem i zrobić spotkanie w szerszym gronie. Można powiedzieć, że zespół ma pewne praktyki i nie zgadza się na pewne rzeczy. Jeśli to nie pomoże, to nie akceptować jego zmian. Zadania w jirze będą wisiały i żadne nie zostanie ukończone. Czy ktoś coś z tym zrobi, to inna sprawa. Gość może sobie pisać, ale zmiany nie będą mergowane.

moze byc ciezko jak tamta osoba pracuje bezposrednio w firmie ;) z mojego doswiadczenia to wlasnie takie osoby bezposrednio zatrudnione mialy wiekszy posluch i byly decyzyjne w projekcie

clonazepam napisał(a):

Natomiast ów człowiek jest mega-oporny na jakiekolwiek uwagi, code-review.

Nikt nie lubi CR, ale jak ktoś może być oporny, to organizacja zespołu/projektu/procesu ma problem. Ustalcie jasne zasady dla wszystkich i regularnie wyciągajcie na światło dzienne ich naruszenia.

Ogólnie zamiast spojrzeć szerzej na to, co modyfikuje i poświęcić trochę czasu żeby zrobić coś bez długu technicznego - kodzi gdzieś na pałę w sumie mając gdzieś kto miał jaki zamysł.

A macie spisane, albo chociaż uzgodnione zasady? Jest jakaś osoba w roli architekta, czy dev leada?

Ostatnio wygląda to tak, że dostaję same bug-tickety po tym jak gość coś rozsypał.

Dopisuje testy, jak je zmieni i wyjdzie bug, to publiczne OPR. CR powinno bardzo wnikliwie przyglądać się zmianom już istniejących testów, bo generalnie to świadczy o tym, że albo ktoś napisał wujowe testy, albo ktoś dał ciała z projektem systemu i trzeba je zmienić, albo ktoś kto dorzucił własny kod leci w kulki.

W review jestem raczej przyzwyczajony do tego, że wszyscy dotąd ludzie biorą to na klatę w ramach różnych skrzywień masochistycznych i dążeń do perfekcji (czasami nawet w trosce o to, nad czym pracują), a jeżeli nie - to przynajmniej mają na to dobry argument.

Jak powinno wyglądać CR to osobna sprawa. Różni ludzie, różne przyzwyczajenia. Trzeba to od czasu do czasu przegadać, żeby nie czepiać się głupot, tylko czytelności kodu, błędów

Natomiast typ potrafi powiedzieć nie bo nie, bo tego nie było w tasku (jeżeli chodzi o jakiś lekki refactor albo sprzątanie po sobie), co pozostawia mnie w sumie bez słów. Klient go lubi, podejrzewam że po prostu bierze bardzo mało kasy więc rozchodzi się po kościach. Dużo by wymieniać, można sobie dopowiedzieć jakieś sytuacje - w sumie wszystko przerobiłem. Już mi się nie chce sprawdzać jego rzeczy.

Jak z tym walczyć, co robić?

Podstawowym sposobem na rozwiązywanie problemów w zespole jest sprawienie, że są one widoczne. Czyli wiadomo jaki jest stan oczekiwany, jakie są rozbieżności ze stanem faktycznym i kto je wprowadził. Część ludzi jest dostatecznie kumatych, żeby zrozumieć i zmienić swoje zachowanie, jak nie pomaga, to przy publicznej rozmowie o problemie wspomina się również kto jest jego przyczyną. Bardzo pomagają w tym narzędzia takie jak statyczna analiza kodu, analiza podatności (Sonarqube), CI (nikt nie może zrobić merge do main line jeżeli jego kod nie przejdzie automatycznych testów, skanów, ręcznego CR). Ważne jest też wskazanie dlaczego mamy takie reguły (bo programiści 90% czasu spędzają na poprawianiu kodu a jedynie 10% na jego pisaniu i warto zainwestować czas w pisanie możliwie bezbłędnego) i danie drogi wyjścia, czyli realnego wpływu na to jak się tworzy aplikację (a przynajmniej prawa do bycia wysłuchanym) i zastanowieniu się nad tym jak pomóc danej osobie w dostosowaniu się, czyli np. pair coding, jakieś wewnątrz zespołowe dyskusje, prezentacje zgodnych rozwiązań. Warto też unikać pyskówek, personalnych wycieczek, ogólnych argumentów "jesteś głupi", tylko skoncentrować się na rozbitych na czynniki pierwsze problemach, sposobach ich rozwiązania i sposobach na uniknięcie w przyszłości.

Przykładowo, ktoś wrzuca metody po 500 linii, albo klasy z wieloma zależnościami, to ustawia się blokującą merge regułę w Sonarqube, git blame dla już istniejącego kodu i rozdzielenie roboty po autorach.

obawiam sie ze developerskie niedbalstwo jest praktycznie nieuleczalne zarowno na poziomie jednostki jak i zespolu, zawsze wyplynie w tej czy innej formie.
na szczescie programisci piszacy albo chociaz chcacy pisac dobry (a nie tylko chyba-dzialajacy) kod nie narzekaja na liczbe ofert pracy. nie masz na co czekac, powodzenia!

O bosz, czytam ten temat i się za głowę łapię. Całe szczęście, że pracuję z domu i widzi to tylko kot.
@clonazepam to jaka jest w końcu twoja rola w teamie? Z opisu wynika, że jesteś zwykłym devem, który ma dostarczać taski i naprawiać bugi, więc dlaczego ty się zabierasz za ocenianie pracy innej osoby z zespołu? Ty masz robić swoje zadania, robić CR, który przechodzi tylko wtedy, jeśli jest "dobry" (czyli przechodzi testy, nie widać tam błędów i stosuje się do stylu, w jakim pisze cały zespół). Czegoś brakuje? Zmiana nie jest zatwierdzona i wisi, dopóki tego nie poprawi. I to jest koniec tego, czego od ciebie oczekuje klient. Ja kompletnie nie mam pojęcia, z jakiego powodu zabierasz się za robotę jakiegoś TL albo PM, bo to w ogóle nie są twoje kompetencje.

@ledi12 @GregoryI wy naprawdę chcielibyście pracować w miejscu, w którym na forum całego zespołu oskarża się pojedyncze osoby o błędy w kodzie? Od kiedy spotkania są od tego, żeby polować na czarownice? I od kiedy rolą deva jest wskazywanie palcem, że ten i ten psuje kod, a jak tamten pisze, to później są bugi? Przecież to brzmi co najmniej jak jakiś mobbing.

W ogóle, tyle się tutaj narzeka, że micromanagement, że managerowie z polski to najgorsze zło i co się w tej Polsce nie dzieje : D no dzieje się, popatrzcie na kolegów z zespołu, przecież połowa propozycji stąd powodowałaby ciągłe kwasy.

tmk3 napisał(a):

O bosz, czytam ten temat i się za głowę łapię. Całe szczęście, że pracuję z domu i widzi to tylko kot.

@clonazepam to jaka jest w końcu twoja rola w teamie? Z opisu wynika, że jesteś zwykłym devem, który ma dostarczać taski i naprawiać bugi, więc dlaczego ty się zabierasz za ocenianie pracy innej osoby z zespołu? Ty masz robić swoje zadania, robić CR, który przechodzi tylko wtedy, jeśli jest "dobry" (czyli przechodzi testy, nie widać tam błędów i stosuje się do stylu, w jakim pisze cały zespół). Czegoś brakuje? Zmiana nie jest zatwierdzona i wisi, dopóki tego nie poprawi. I to jest koniec tego, czego od ciebie oczekuje klient. Ja kompletnie nie mam pojęcia, z jakiego powodu zabierasz się za robotę jakiegoś TL albo PM, bo to w ogóle nie są twoje kompetencje.

A gdzie wchodzę w kompetencje TL albo PM? Bo nie rozumiem. Tego z ocenianiem pracy też.
Mówię o tym jak mi się z nim współpracuje w review i tyle.

tmk3 napisał(a):

@ledi12 @GregoryI wy naprawdę chcielibyście pracować w miejscu, w którym na forum całego zespołu oskarża się pojedyncze osoby o błędy w kodzie? Od kiedy spotkania są od tego, żeby polować na czarownice? I od kiedy rolą deva jest wskazywanie palcem, że ten i ten psuje kod, a jak tamten pisze, to później są bugi? Przecież to brzmi co najmniej jak jakiś mobbing.

W ogóle, tyle się tutaj narzeka, że micromanagement, że managerowie z polski to najgorsze zło i co się w tej Polsce nie dzieje : D no dzieje się, popatrzcie na kolegów z zespołu, przecież połowa propozycji stąd powodowałaby ciągłe kwasy.

Jeżeli delikwent notorycznie przejawia arogancje (bo inaczej tego nazwać nie można) to dlaczego inni mają z tego powodu zbierać baty? Można kogoś upomnieć raz, drugi i nie chodzi tutaj o popełnienie błędów bo każdy ma do tego prawo. Chodzi o fakt, kiedy delikwent nie widzi w swoim zachowaniu nic złego mimo jasnych sygnałów innych członków zespołu.

clonazepam napisał(a):

A gdzie wchodzę w kompetencje TL albo PM? Bo nie rozumiem. Tego z ocenianiem pracy też.
Mówię o tym jak mi się z nim współpracuje w review i tyle.

No to prosto - jaka jest twoja rola w zespole? Bo z twoich postów wynika, że jesteś po prostu developerem - czyli dostajesz taski, które sobie dziergasz, jak są bugi, to je naprawiasz, zamykasz komputer i idziesz do domu (wiem, że spłaszczam twoje obowiązki, ale do tego można je streścić). Nie masz w obowiązkach zajmowania się zespołem, jakiejś pieczy nad tym devem ani nic takiego, więc po co próbujesz to robić? Jeśli macie spisane zasady tego, jak ma kod wyglądać, to wpisujesz to w komentarzu do review i czekasz, aż naprawi. Nie naprawił? Nie przechodzi, i tyle masz robić. Wskazywanie palcem na spotkaniach to zwykły mobbing i tyle. To TL albo PM za niego odpowiada, a nie ty.

ledi12 napisał(a):

Jeżeli delikwent notorycznie przejawia arogancje (bo inaczej tego nazwać nie można) to dlaczego inni mają z tego powodu zbierać baty? Można kogoś upomnieć raz, drugi i nie chodzi tutaj o popełnienie błędów bo każdy ma do tego prawo. Chodzi o fakt, kiedy delikwent nie widzi w swoim zachowaniu nic złego mimo jasnych sygnałów innych członków zespołu.

Zaraz, ale kto zbiera jakieś baty? Nic nie widziałem o tym, żeby OPowi dostawało się za to, że jakiś inny dev napisał kod, który spowodował bugi, więc jakie baty zbiera? Napisałem - nie zatwierdzasz review, dopóki nie poprawi błędów, a jak ich ciągle nie poprawia i kod nie przechodzi dalej, to jest to już sprawa dla managementu, a nie dla deva z zespołu. Jak manager bierze to w koszty, że gość zrobi błędy, to tobie nic do tego, bo to nie są twoje kompetencje.

I tak, może ci się nie podobać, że gość nie pisze w taki sposób, jaki sobie wymarzyłeś, ja nie mówię, że to nie jest problem. To problem duży, ale to nie ty masz się nim zajmować, tylko ktoś nad wami. Jeśli zespół ma działać w zdrowy sposób, to musisz znać swoje kompetencje. Co najwyżej możesz zmienić zespół, ale nie robić kwasów na spotkaniu ze wszystkimi, bo to ci się odbije.

tmk3 napisał(a):

@ledi12 @GregoryI wy naprawdę chcielibyście pracować w miejscu, w którym na forum całego zespołu oskarża się pojedyncze osoby o błędy w kodzie? Od kiedy spotkania są od tego, żeby polować na czarownice? I od kiedy rolą deva jest wskazywanie palcem, że ten i ten psuje kod, a jak tamten pisze, to później są bugi? Przecież to brzmi co najmniej jak jakiś mobbing.

Jeżeli ktoś olewa ustalone wcześniej konwencje, nie stosuje się do CR, ignoruje zgłoszone komentarze na zasadzie "nie bo nie" (i mówiliśmy tutaj w tym wątku o takich właśnie sytuacjach - nie dopowiadaj sobie prześladowania niewinnych bidulek które nic nie zrobiły), a co więcej, jego błędy, opieszalstwo lub upór zaczynają rzutować na moją pracę bo z jego strony leci przekaz "ale ja już zrobiłem", to jak najbardziej mam prawo poinformować mojego Team Lead lub PM, że jest taki a taki problem i proszę, żeby miał takiego delikwenta w głowie, że coś jest na rzeczy. Może ty byś go poklepał po główce i uśmiechnął się, ale nie ja.

Daily nie jest też od wskazywania paluchem że ktoś pisze zły kod, jest od przekazania aktualnych informacji co na jakim jest etapie, co się robi, czy są blokery bo coś czeka na coś innego. Jeśli są blokery przez taką osobę, to należy o tym powiedzieć, bez personalnej wycieczki. Nie wiem w jaki sposób przeczytałeś to co napisałem, ale bardzo emocjonalnie odpisałeś coś o mobbingu oraz mówieniu przy wszystkich że ktoś pisze chu••wy kod. Pracowałeś kiedyś z ludźmi? Widzisz różnicę w powiedzeniu na daily jak ktoś pyta dlaczego coś wisi, że "nie możemy zrobić merge, ponieważ czekamy na poprawki z CR w zmianie od XXX", albo "zmiana od XXX nie została jeszcze zmergowana, bo są tam jakieś poprawki do skończenia"? To jest dla ciebie polowaniem na czarownice i poniżenie kogoś przy wszystkich?

I jeszcze jedna rzecz: a czyją rolą jak nie rolą dewelopera (osoby która pisze kod na projekcie) jest przekazanie wyżej że jest osobnik (też deweloper) który jest szkodnikiem? Scrum master sobie wyczyta z wykresu spalania? Nietechniczny PM zagai w trakcie obiadu z pytaniem o historyjkę? Team Lead będzie sprawdzał kod każdego z osobna i wyłapie właśnie jego, że coś jest nie tak?

@tmk3: Za jakość produktu, terminowość dostarczenia zmian, bezpieczeństwo rozwiązania odpowiada zespół. Jak jestem członkiem tego zespołu, to nie przepadam za ludźmi, którzy rozwalają pracę i mają ujemny wpływ na tempo pracy, bo nie dość, że nie dostarczają żadnej wartości, to jeszcze trzeba marnować czas na poprawianie po nich. Nie piszę o tym, że ktoś popełni błąd lub czegoś nie wie, tylko o zlewaniu komentarzy z CR i podobnych zachowaniach. Na poziomie zespołu mogę i powinienem podnosić takie problemy, bo dotyczą one wszystkich. Jeżeli to ten "ktoś" ma rację, to też może to uargumentować na poziomie zespołu i przekonać pozostałych. Jeżeli to nie działa, to od tego mam jakiegoś managera, żeby się tym martwił, szczególnie, że ma do tego narzędzia - może pogadać z zainteresowanym, innymi członkami zespołu, może poprosić o niezależną opinię kogoś z poza zespołu. To czego nie będę robił, to nie zauważał, że ktoś robi kupę do doniczek, bo może trochę śmierdzi, ale takie ma nawyki, mogę się przyzwyczaić, no i kwiatki lepiej rosną.
W ekstremalnym przypadku dopisywałem się do wszystkich PR'ów pewnej osoby i nie przepuszczałem dalej do momentu uzyskania zadowalającego kształtu. Nie wiem czy czyni mnie to "polaczkiem", trochę mało mnie to obchodzi. Wiem, że i zespół był mi za to wdzięczny.

clonazepam napisał(a):

Natomiast ów człowiek jest mega-oporny na jakiekolwiek uwagi, code-review.
...
Ostatnio wygląda to tak, że dostaję same bug-tickety po tym jak gość coś rozsypał.

Mylisz 2 rzeczy:

1. Uwagi dotyczace np. stylu czy "dobrych praktyk". Co gorsza zakladasz ze masz racje przy uwagach. A nawet jesli wiekszosc zespolu mysli podobnie, to wcale to co sie wam wydaje nie musi w rezultacie powodowac powstania "lepszego" kodu. Co innego jesli ustaliliscie jakies konwencje i ktos ich nie przestrzega. W takiej sytuacji takiego kodu sie po prostu nie merguje. Idealnie gdyby to wymuszal automat (choc w mojej, czysto subiektywnej, opinii jesli ustaliliscie konwencje dla ktorych istnieje automat ktory umie je wymusic, to znaczy ze sie uparliscie zeby pisac nieczytelny kod i marnowac czas na gimnastyke jak te konwencje spelnic w niektorych sytuacjach).
   Czyli dla tej wersji problemu bez wzgledu czy dev jest geniuszem czy idiota, to problem jest po stronie prowadzenia projektu. Albo nie macie zadnych zasad (a pozniej jakies losowe zasady probujecie wymuszac) albo nie macie zadnego mechanizmu wymuszenia przestrzegania istniejacych zasad.
2. Bugi. Jesli ignoruje zglaszane bugi to znaczy ze jest niekompetentny i nalezy natychmiast to komunikowac wyzej. I oczywiscie nie wolno mergowac. Choc podejzewam ze w praktyce na review bugi nie sa znajdowane. No ale za to ze recenzent nie znalazl bugow nie mozna winic autora kodu. Ok, jest mozliwe takie zobfuscatowanie kodu zeby nie dalo sie nic znalezc. Ale praktyka pokazuje ze bez wzgledu na to jak kod jest napisany oczywiste bugi sa mergowane. No chyba ze recenzent poswieci wiecej czasu niz dev (dokladne poznanie wszystkich aspektow taska + analiza cudzego kodu). Nie idealne, ale jakies rozwiazanie, to juz inni podali - zapewne nie macie, lub macie malo testow. Wystarczy je napisac. Mimo ze tez nie zapewni 100% poprawnosci, to dodatkowo pozwalac na commit tylko dla X% pokrycia kodu testami.