Pytanie:
Współpracownik zbyt późno przegląda kod
Henrik Rosseau
2018-11-20 10:26:23 UTC
view on stackexchange narkive permalink

Latem zmieniłem pracę z dużej firmy jako starszy inżynier na znacznie mniejszą firmę jako główny inżynier. Teraz nadzoruję około 20 inżynierów średniego i średniego szczebla pracujących nad 3 różnymi systemami rezerwacji. Wszystkie systemy rezerwacyjne działają na tej samej zastrzeżonej platformie zaplecza, zarządzanej przez inny zespół, którego nie nadzoruję.

W zeszłym miesiącu w nocy przed wydaniem dużego wydania jednego z systemów rezerwacji, starszy inżynier („Clint”) w zespole wsparcia zaplecza zostawił kilka komentarzy na temat żądania ściągnięcia, które otworzyliśmy, aby scalić naszego kandydata do wydania z Master

Opinie były różne od nieco pomocnych do nieco nieprzydatnych. W każdym razie połączyliśmy się z Master i następnego dnia zapytałem, czy mógł przejrzeć ten kod wcześniej, zamiast czekać do zakończenia testów integracji. Kiedy zostawił opinię, był już koniec dnia i przygotowywaliśmy bilet dla naszego inżyniera ds. Wersji do wdrożenia o 4:30 rano następnego dnia.

Powiedział mi, że nie jest jego zadaniem nauczanie moi inżynierowie (ma rację, nie jest). Trudno mi jednak trenować jednocześnie 20 inżynierów, nawet jeśli przeprowadzają wzajemne oceny i wzajemnie kontrolują kod. Martwię się również, że mój zespół był trochę zdemotywowany, ponieważ nie był w stanie zrobić nic, aby odpowiedzieć na opinie.

Mamy zaplanowane kolejne wydanie zaraz po powrocie z Święta Dziękczynienia i na podstawie tego, jak Clint's odmówił wszystkiego nasze zaproszenia na spotkanie przeglądu kodu w tym miesiącu, myślę, że zobaczę powtórkę tego samego za kilka dni.

Nie mogę powiedzieć, czy Clint naprawdę chce pomóc, czy po prostu naprężyć swoje ego . Chciałbym, żeby pomógł w coachingu naszych młodszych programistów, ale sposób, w jaki to robi, jest niepomocny. Nie sądzę, żeby moi inżynierowie kiedykolwiek byli w stanie złapać wszystko, co potrafi Clint.

Jak mogę powiedzieć Clintowi, że chce przekazać opinię, musi to być na naszych warunkach?

EDYTUJ : Jestem zażenowany, że pominąłem ten szczegół, ale nasi inżynierowie otwierają żądania ściągnięcia z ich gałęzi funkcji do development , do którego powinny trafiać te opinie (w przypadku żądań) ... kiedy wszystkie te zmiany są gotowe do przejścia do naszego środowiska produkcyjnego (po przeprowadzeniu testów integracyjnych przez naszych inżynierów QA i zweryfikowaniu, że zmiany są według nich bezpieczne) otwieramy żądanie PR, aby scalić je z Master po zatwierdzeniu przez inżyniera zmian i ustaleniu, że nie wprowadziliśmy nic strasznego, a następnie wdrożymy następnego ranka

Jaka jest rola Clinta w procesie PR / fuzji?Czy potrzebujesz jego recenzji, aby umożliwić scalenie?Czy on tylko udziela porad?
Jaki jest tutaj ogólny proces?Z tego, co napisałeś, wynika, że testy integracyjne zostały wykonane i masz otwarty PR do scalenia z master, a także sugerujesz, że w rezultacie wdrożysz z poziomu głównego.Dlaczego PR jest wykonywany po testach integracyjnych?Jak długo działał PR?Jakie były inne możliwości uzyskania opinii?Co stanie się z twoimi testami, jeśli pojawi się komentarz PR, który podkreśla fundamentalny problem?Wygląda na to, że jest wiele do omówienia tutaj w szerszym kontekście z całym zespołem i niekoniecznie jest to kwestia, w której Clint komentuje PR imho.
Dlaczego czekałeś do ostatniej możliwej chwili na połączenie?Czy jest jakiś powód, dla którego nie zamierzałeś połączyć się kilka godzin wcześniej, w którym to momencie prawdopodobnie byłoby wystarczająco dużo czasu, aby odpowiedzieć na jakiekolwiek uwagi?Jeśli żądanie ściągnięcia jest otwarte, oczekuje się, że ludzie zostawią komentarze - wydaje się to bardziej problemem po Twojej stronie niż po ich stronie.Poza tym, skąd miał wiedzieć, że nie powinien komentować?Zwróć uwagę, że jeśli same komentarze proszą o marnowanie czasu na niepotrzebne zmienianie rzeczy, masz inne pytanie do rąk.
OP musi to wyjaśnić, ale dla wszystkich komentujących sugerujących, że PR powinien był zostać wykonany wcześniej, jeśli ich proces jest podobny do tego, w którym pracuję (przepływ git), wówczas PR / merge to master jest sposobem wdrożenia na produkcjęrozsierdzony.Byłoby wiele wcześniejszych PR do gałęzi deweloperskiej (lub głównej) dla każdej indywidualnej funkcji, a także do różnych gałęzi wydań dla QA lub innych środowisk.Przeglądy kodu powinny się wtedy odbyć, a nie przy ostatecznym scalaniu do mastera.
@sleske Świetne pytanie!To może być źródłem naszego problemu, ale uważam, że jego rola polega na informowaniu nas, że żadna z naszych zmian nie jest szkodliwa na podstawie tego, co rozumie na temat platformy rezerwacyjnej.Mogę się scalić bez jego recenzji, a on tylko udziela porad
@Moo Dziękuję za przemyślaną odpowiedź, mam nadzieję, że mogę wystarczająco dobrze opisać cały proces: inżynierowie QA łączą gałęzie funkcji jeden po drugim z naszą gałęzią programistyczną, a następnie wdrażamy gałąź programistyczną w naszym środowisku deweloperskim w celu testowania integracji.Jeśli testy zakończą się pomyślnie, łączą programowanie i mastering do testów dymnych w środowisku pomostowym.Zmiany są scalane do mastera dopiero po przejściu testów integracji i poprzez żądanie ściągnięcia jako dodatkowa możliwość przechwycenia istotnych zmian.Chciałbym otrzymać jego opinię wcześniej, kiedy możemy odpowiednio zareagować, ale on nie chce jej wtedy udzielać
@Dukeling Staramy się, aby gałąź Master była zsynchronizowana z produkcją i wdrażała wkrótce po połączeniu z nią.Nasi inżynierowie ds. Kontroli jakości oczekują dnia na przetestowanie zmian w gałęzi programistycznej przed połączeniem się z wersją Master w celu przetestowania dymu i wdrożeniem do produkcji wkrótce potem.Moje pytanie dotyczy ograniczania opinii do rzeczy, które blokowałyby wdrożenie, gdy osoba oferująca informacje zwrotne nie chce tego rodzaju ograniczenia
@DavidConrad Tak, wystarczająco blisko.Nie jest to automatyczne, ale staramy się trzymać nowe zobowiązania poza Master, dopóki nie zostaną dokładnie przetestowane i nie będziemy gotowi do wdrożenia do produkcji
Przegląd kodu jego przeglądu kodu?Przegląd przeglądu kodu: „Ciekawe informacje zwrotne. Nieprawidłowe w miejscach. Wymaga bardziej aktywnego podejścia. Przećwicz lepsze wyczucie czasu”.
Nie wspominasz nigdy o informowaniu Clinta, kiedy spodziewasz się, że do dnia skompletuje informację zwrotną.Czy w ogóle przekazałeś mu jakąś linię czasu?Jeśli masz ramy czasowe, z którymi musi pracować, musi o tym wiedzieć, aby przekazać swoje zadania i priorytety przełożonym.
Dziesięć odpowiedzi:
Joe Stevens
2018-11-20 10:49:49 UTC
view on stackexchange narkive permalink

O ile Clint nie znajdzie żadnych głównych błędów, „nie wdrażaj”, po prostu podziękuję mu za jego opinię i wyjaśnię mu, w jaki sposób zamierzasz zająć się kwestiami, które podnosi (jeśli są ważne) w przyszłych wydaniach.

Jeśli ma z tym problem, możesz wyjaśnić, dlaczego lepiej byłoby, gdyby wcześniej wyraził swoją opinię.

Ostatecznie jest to jego problem przekazuje opinie tak późno. Nie rób tego, traktując je jako osobistą / zespołową porażkę.

+1 to dobra odpowiedź.Informacja zwrotna to informacja zwrotna, ale zgodnie z odpowiedzią, chyba że „Clint” znalazł jakiś problem z blokerem, zajmiemy się nią później.Jeśli „Clint” nie jest z tego zadowolony, może wcześniej przejrzeć kod.
Czy nadal powiedziałbyś, że to jego problem, gdyby nie wiedział, że tego wieczoru chcą się połączyć?
To nie jest jego problem, jeśli była to jego pierwsza prawdziwa okazja do wyrażenia opinii.A nawet gdyby tak było, jego problem polega na tym, że twój problem jest problemem wszystkich, ponieważ wszyscy jesteście częścią tego samego zespołu i wszyscy chcą, aby odniósł sukces, prawda?
Nie rozumiem, dlaczego to problem Clinta.Clint jest częścią innego zespołu, wydaje się, że przekazuje informacje zwrotne niezależnie od procesu.Problem w tym, że OP nie postrzega go jako bardzo użytecznego (ze względu na czas).Myślę, że nikt nie ma jasnego pojęcia, o czym powinien być przegląd kodu, albo każdy ma swój pomysł.Może służyć wielu celom.Powinny znaleźć się na tej samej stronie.
Myślę, że ta odpowiedź jest prawidłowa - po prostu nie widzę tutaj żadnego „problemu”.Może nie rozumiem?Clint dostarczył nowych informacji, z których niektóre zdaniem OP są cenne.Niesamowite.To zawsze dobra rzecz.Jeśli te informacje wskazują, że nie możesz wdrożyć, scalić lub cokolwiek innego, lepiej jest wiedzieć jak najszybciej.Jeśli te informacje wskazują na drobne problemy, niesamowite, zaloguj się i odpowiednio segreguj.Żadnych problemów.Jeśli chcesz być bardziej wrażliwy na opinie Clinta, to na pewno musisz go wcześniej zaangażować, ale nadal uważam to za całkiem dobrą sytuację.
Tak powinna sobie radzić firma.Błędem jest myślenie, że każdy komentarz do przeglądu kodu wymaga działania.Kiedy już złapiesz jakieś oczywiste błędy (miejmy nadzieję, że przez pierwszą osobę, która przejrzy), wiele komentarzy będzie brzmiało „rzeczy, które byłoby fajnie zrobić” lub „rzeczy do zrobienia lepiej następnym razem” lub po prostu „rzeczy, które mógłbyś zrobić inaczej, alemoże będzie dalej robić to samo ”.
Lol, to problem Clinta w tym sensie, że * JEŚLI * chce, aby jego opinie były traktowane poważnie, * WTEDY * to Clint musi zapewnić takie informacje wystarczająco wcześnie w procesie.
Komentarz na koniec dnia dotyczący wdrożenia następnego dnia o 4:30?Do licha, zmieniłem procedury, aby zezwolić na wdrożenia tylko od poniedziałku do środy, ponieważ ktoś wpadł w piątkową pracę po dniu roboczym i stworzył ogromną ilość pracy w poniedziałek.Clint nie powinien był oczekiwać, że informacje zwrotne będą przydatne, z wyjątkiem najpoważniejszych błędów typu show-stopper.
Nie dotyczy to sposobu omawiania tego problemu z zespołem.Ale to dość oczywiste - wyjaśniasz zespołowi, że jest to bardzo pomocna informacja zwrotna, która pozwoli im następnym razem poradzić sobie lepiej.Żaden wdrożony kod nie jest doskonały i zawsze są rzeczy, które można zrobić lepiej, a ktoś, kto zwraca na to uwagę, pomaga w nauce.
Dodam też, że jest to również kwestia zarządzania.Wszystkie przeglądy kodu należy przeprowadzić przed kontrolą jakości.Poprawki kodu przed QA są tanie, a poprawki kodu po QA są drogie, ponieważ musi on ponownie przejść kontrolę jakości;to jest naprawiane tylko wtedy, gdy jest to blokada pokazu.Jeśli ktoś przeprowadza kontrolę jakości kodu, to marnuje pieniądze firmy.Albo należy zająć się tym procesem, aby przegląd kodu odbywał się na czas, albo wcale.
@RobP.Problem, który widzę, polega na tym, że OP traktuje opinie Clinta zbyt poważnie.Wyraźnie nie ma to zastosowania do tworzonego wydania, ponieważ Clint prawdopodobnie nie będzie idiotą, więc należy o tym pamiętać przy przyszłych wydaniach.
gnasher729
2018-11-20 17:40:16 UTC
view on stackexchange narkive permalink

Albo przegląd kodu jest wymagany do wydania, albo nie jest wymagany. Jeśli jest to wymagane, recenzent musi być odpowiedzialny za sprawdzenie tego w odpowiednim czasie. Musisz mieć prawo podejść do jego biurka i powiedzieć „rzuć wszystko inne i zrób tę recenzję, albo nie możemy ustalić daty wydania”. I musisz mieć moc powiedzenia „przepraszam, nie mogliśmy wydać na czas, ponieważ recenzja nie została ukończona na czas”.

Jeśli nie jest to wymagane, zwalniasz.

PS. Jeśli Clint ma jeden dzień na przejrzenie tygodni lub miesięcy pracy, wydaje się to wskazywać, że przegląd nie był potrzebny. Ale jeśli Clint napotka problemy w tak krótkim czasie, wydaje się to wskazywać, że poprzednie recenzje nie były tak dobre, jak powinny.

+1 - odpowiedzialność bez uprawnień do robienia rzeczy to problem, który widziałem częściej niż bym chciał.
Biorąc pod uwagę, że „Clint” miał najwyraźniej mniej niż jeden dzień na przejrzenie roboczogodzin lub może osobomiesięcy pracy, ta odpowiedź wydaje się bardzo chybiona.Sprawienie, by recenzent był „odpowiedzialny” za przeglądanie kodu szybciej, niż jest to w rzeczywistości możliwe, jest oczywiście nieracjonalne.A ponieważ Clint najwyraźniej * zdołał * zostawić kilka przydatnych komentarzy w ciągu kilku godzin, które miał, tym bardziej perwersyjne wydaje się sugerowanie, że wszystko byłoby naprawione, gdyby tylko PO miał możliwość zmuszenia Clinta do porzucenia własnych priorytetów i przeglądualbo winić Clinta za to, że jest zbyt wolny.
@MarkAmery Nie widzę w pytaniu żadnej wskazówki, że czas Clinta był ograniczony przez OP.Gdyby OP miał moc zadawania pytań „ile czasu potrzebujesz na sprawdzenie?”a potem moc powie „OK, więc musisz zacząć w dniu X lub wcześniej, ponieważ potrzebujemy informacji zwrotnej przed Y”, wtedy byłoby OK.Jeśli OP nie może tego zrobić, nie powinien odpowiadać za brak odpowiedzi na informację zwrotną.To powinien być problem zarządzania, a nie OP.Nie chodzi o obwinianie Clinta, ale o nie wymaganie od OP i jego zespołu dokonania niemożliwego.
+1 Ponadto zespół OP może odnieść się do opinii non-blocker przed kolejną wersją.
@Mołot Wuj Ben Petera Parkera był blisko, kiedy powiedział: „z wielką mocą wiąże się wielka odpowiedzialność”.Nie spotykają się.To ta sama rzecz.Jeśli nie mam możliwości kontrolowania tego, jak coś się dzieje, nie odpowiadam za to, jak to się robi źle.Zbyt wiele osób próbuje oddzielić od siebie władzę i odpowiedzialność, ale po prostu nie można tego zrobić, a próby tego kończą się niepowodzeniem.Za każdym razem, gdy ktoś próbuje pociągnąć mnie do odpowiedzialności w sytuacji, w której nie mam władzy, mówię „jak myślisz, co właściwie mógłbym zrobić inaczej, aby zapobiec $ {BAD_THING}?”;odpowiedź zazwyczaj brzmi „nic”.
@MontyHarder Ponowne zdefiniowanie terminu „odpowiedzialny” w celu dopasowania go do bieżącej dyskusji nie jest raczej korzystne.Jeśli zapytają Cię o recenzję i oczekują Twojej * odpowiedzi *, a Ty odpowiadasz (głównie dlatego, że wewnętrznie wiążesz odpowiedź z Twoim profesjonalnym obrazem siebie), to wszystko: jesteś tak samo * odpowiedzialny * za rzecz jak onadostaje.Możesz dopasować się do takiej definicji bez pełnej władzy i kontroli nad każdym aspektem.
@Mołot W mojej interpretacji sekwencji wydarzeń było mniej niż 24 godziny między otwarciem PR (a tym samym dostępnym dla Clinta do przejrzenia) a połączeniem go z jego zastrzeżeniami.OP potwierdza tę interpretację.Został otwarty w pewnym momencie w ciągu dnia roboczego, Clintowi udało się wbić jakąś recenzję, a następnie zespół zignorował to wszystko i połączył się o 4:30 rano następnego dnia, a OP obwiniał Clinta, że nie sprawdził wcześniej PR, że *jeszcze nie istniał *.Wydaje mi się to dość szalone.
@MarkAmery w takich okolicznościach jest to problem z harmonogramem.I nadal uważam, że OP powinien być w stanie zapytać, ile czasu potrzebuje Clint i odpowiednio zaplanować, albo, jeśli nie ma mocy wspomagania, OP nie powinien być obwiniany przez krótki czas, jaki miał Clint, lub przegląd faktów został zignorowany.Jedyną winną jest osoba, która zaprojektowała tak napięty harmonogram.
@Mołot Jasne, to może być poza zasięgiem OP.(A może nie. Zakładasz, myślę, że harmonogram był poza kontrolą PO, ale nic nie potwierdza tego w pytaniu; PO zarządza dużym zespołem i wiarygodnie ustala lub przynajmniej wpływa na ich harmonogram).nie wymienia odpowiedzi, która obwinia sytuację konkretnie i wyłącznie z powodu braku władzy PO * nad Clintem *, kiedy PO przyznaje, że Clint natychmiast zostawił pożyteczną informację zwrotną tego samego dnia, w którym dano mu coś do przejrzenia.Żadna ilość mocy nie pozwoli OP zmusić Clinta do przeglądu kodu, zanim on zaistnieje.
@MarkAmery Zgodnie z pytaniem, Clint został zaproszony do przeglądu kodu, ale go nie zaakceptował.Nie ma dowodów na to, że OP wstrzymuje kod do późnej fazy procesu.Clint najwyraźniej sam decyduje się na przegląd dopiero pod koniec procesu.Wniosek jest taki, że Clint nie uważa, że wkład, jaki mógłby uzyskać, nie jest wart jego czasu.
@DavidThornley Tak, zgodnie z pytaniem Clint został * teraz * zaproszony na spotkania przeglądu kodu.Nawet jeśli weźmiemy jego odrzucenie jako dowód, że * decyduje * się nie przeglądać do końca procesu (w przeciwieństwie do, powiedzmy, kłótni z ważniejszymi spotkaniami lub gdy menedżer poinstruował go, aby nie spędzał czasu na innychpraca zespołu dla nich), nie ma to nic wspólnego z poprzednim incydentem opisanym przez PO.Wniosek w ogóle nie płynie, ponieważ nie mamy informacji, dlaczego Clint odrzucił spotkania.
Joe McMahon
2018-11-21 05:03:14 UTC
view on stackexchange narkive permalink

Wygląda na to, że jest tu kilka problemów, ale wszystkie można rozwiązać.

Problemy z procesem:

  • Jaki jest cel tego żądania ściągnięcia? Czy jest przeznaczony do przeglądu, czy jest to po prostu sposób na połączenie się z master z poddanej kontroli jakości i przetestowanej gałęzi? W pierwszym przypadku należy rozważyć inne planowanie procesu przeglądu. Jeśli to drugie, powinno zostać scalone niemal natychmiast po utworzeniu.
  • Co robisz z „późnymi” komentarzami do recenzji? Wygląda na to, że komentarze Clinta nie przeszły przez cały proces recenzji, mimo że były „spóźnione”. (Co definiuje „spóźnione”?) Nawet jeśli zdecydowałeś się na scalenie i żaden z komentarzy nie przeszkadza, powinno być możliwe sklasyfikowanie jego komentarzy jako możliwych do podjęcia działań lub nie, i odpowiadanie w odpowiednim żądaniu.

Problemy osobiste:

  • Dostaję tu trochę wrażenia „nie wszyscy jesteśmy jednym zespołem”. Może to wynikać ze zrozumiałej frustracji z twojej strony, ale jeśli szanujesz Clinta - i jak rozumiem - warto spróbować to naprawić. Może teraz odrzucać twoje prośby o spotkanie przeglądowe, ponieważ jest zajęty, lub może czuć, że i tak naprawdę nie chcesz jego wkładu.
  • Wypełnij, aby pokazać swoje prawdziwe intencje. Jeśli uważasz, że niektóre z rzeczy, które powiedział, były prawdziwymi problemami, złóż bilety i upewnij się, że jest na nich uwzględniony.

Pozostawienie otwartego PR do „prawdziwej recenzji” aż do wieczora przed wysłaniem oznacza, że ​​musisz traktować wszystkie recenzje poważnie i nie łączyć i nie przesyłać, jeśli są bezadresowe komentarze, lub musisz zmienić harmonogram wypychania, aby mieć wystarczająco dużo czasu na zakończenie przeglądu i zaplanowanie lub anulowanie wypychania (np. PR nie scalone co najmniej 24 godziny przed zaplanowanym wysłaniem nie wychodzą).

Dobrym pomysłem byłoby zaprosić go na kawę i porozmawiać o tym, dając mu do zrozumienia, że ​​tak, cenisz jego wkład, ale proces w obecnej postaci oznaczał, że nie otrzymałeś jego recenzji wystarczająco wcześnie, aby tym razem działać, podkreślając „tym razem”. Poinformuj go, że chcesz zmienić proces, i zapytaj, czy ma jakieś sugestie.

Zapytaj go, co ułatwiłoby mu udział, i upewnij się, że rozumie, że doceniasz to, że mu przeszkadzał. Jeśli naprawdę stara się pomóc, to żadne działanie w jego komentarzach również nie zniechęca go . Wygląda na to, że nie było żadnych korków, odkąd dokonałeś fuzji, ale wygląda na to, że z jego punktu widzenia praca była zmarnowanym wysiłkiem.

Podziękuj mu za znalezienie wskazanych przez niego problemów i daj mu znać, że masz zamiar zająć się istotnymi sprawami, które poruszył. Powinieneś rozważyć zrobienie tego zarówno z nim jeden na jeden, jak i publicznie w zamkniętym PR, aby było jasne dla niego i zespołu, że cieszysz się, że pomaga. Okazywanie wdzięczności, prywatnie i publicznie, za jego troskę i ochotniczą pomoc, nawet jeśli żaden komentarz z recenzji nie był przydatny z punktu widzenia Twojego zespołu, jest po prostu uprzejmą rzeczą i pomaga budować solidarność między zespołami.

Aby być bardziej szczegółowym, jeśli chodzi o powód „zajętości”, Clint może czuć, że jest wciągany do zespołu i obciążenie pracą, które nie jest jego obowiązkiem, skoro ma już wystarczająco dużo (a może nawet za dużo!) Własnych zmartwień.W takim przypadku włączenie go do raportów o błędach i podjęcie innych wysiłków, aby poczuł się bardziej zaangażowany / ceniony, może w rzeczywistości działać na szkodę związku.
Inżynierowie wsparcia IME są często przeciążeni.Byłoby pomocne, gdyby znalazł powody, dla których Clint odrzucał zaproszenia do przeglądu kodu (może po prostu być zbyt zajęty).Poinformowanie Clinta, że jego wkład jest cenny, jakkolwiek późny, byłoby dobrym sposobem na zbliżenie go do zespołu OP.Jeśli Clint ma zdolności, ale czuje, że nie jest wystarczająco blisko, aby zaangażować się wcześniej, może po prostu czuć się nieswojo, depcząc innym ludziom palce.
Tak, właśnie dlatego wychodzisz na kawę i rozmawiasz o tym.Wydaje się, że tym razem zgłosił się na ochotnika, więc sprawdzanie, czy i jak chciałby wnieść swój wkład, wydaje się najbardziej bezpośrednim sposobem rozwiązania problemu, aw nieformalnym otoczeniu może oderwać się, jeśli czuje się tak, jaknie był ceniony.
Joe Strazzere
2018-11-21 05:39:45 UTC
view on stackexchange narkive permalink

Jak mogę powiedzieć Clintowi, że chce przekazać opinię, musi to być na naszych warunkach?

Chyba że Clint dla ciebie pracuje lub jest jakiś formalny procesu, który dyktuje, kiedy komentarze są niedozwolone, nie możesz zmusić Clinta do przestrzegania "twoich warunków".

Możesz zignorować jego komentarze. Możesz mu podziękować za „nieco pomocne” komentarze, aby zachęcić do nich więcej. Możesz dodać elementy do swojego rejestru technicznego, aby zająć się tymi pomocnymi komentarzami. Możesz nadal zapraszać go na spotkania przeglądu kodu. Możesz zachęcić swój zespół, aby nie tracił motywacji na podstawie kilku spóźnionych komentarzy.

Ertai87
2018-11-20 21:35:16 UTC
view on stackexchange narkive permalink

1) Czy między tobą a 20 inżynierami nie ma nikogo, kto mógłby pomóc ci w ich mentorowaniu? Dlatego 20 osób to za dużo osób w zespole, ponieważ nie ma możliwości, aby jedna osoba mogła zarządzać i mentorować 20 osób. Musisz zmniejszyć rozmiar swojego zespołu lub przynajmniej zmniejszyć rozmiar swojej odpowiedzialności, ponieważ jesteś zbyt cienki.

2) Jeśli chodzi o publikację kodu, czy Clint jest w twoim zespole? Jeśli Clint jest w twoim zespole, to Clint powinien być zaangażowany w przeprowadzanie przeglądów kodu, zwłaszcza jeśli jest starszym inżynierem. Jeśli to możliwe, zachęcaj swoich podopiecznych do wysyłania recenzji kodu do Clinta (nie przeciążaj go, ale zachęcaj ich do zaangażowania Clinta w ten proces). Jeśli Clinta nie ma w twoim zespole, to jeśli problemy znalezione przez Clinta nie są błędami krytycznymi dla operacji, poproś go, aby zarejestrował je jako zgłoszenia błędów; Nie ma go w Twoim zespole, nie odpowiada za Twój produkt.

4) Co do pominięcia Clinta na „spotkaniach przeglądu kodu”: Po pierwsze, nie jestem pewien, co to jest „spotkanie w sprawie przeglądu kodu”. Przeglądy kodu to operacje asynchroniczne: programista przesyła kod, recenzent kodu przegląda, podczas gdy programista robi coś innego, kończy recenzję, komentuje deweloperów, przepłukuje, powtórz. Nie wiem, co to jest „spotkanie przeglądu kodu”, to brzmi głupio. Ale poza tym, jeśli Clint jest w twoim zespole, Clint powinien uczestniczyć w spotkaniach zespołu. Jeśli Clinta nie ma w Twoim zespole, Clint nie musi uczestniczyć w spotkaniach zespołu. To takie proste.

„Spotkania dotyczące przeglądu kodu” - kiedyś to robiliśmy.Raz w tygodniu jeden z głównych deweloperów sprawdzał różne niedawne żądania scalenia i wskazywał różne przykłady szczególnie dobrego i złego kodu, a konkretnie, co było w nim dobre, a co złe.Wtedy każdy miałby o tym wielką dyskusję.To świetny sposób na przekształcenie wiedzy z doświadczenia w coś, co młodzież może zrozumieć i przyswoić.
Przeglądy kodu mogą być asynchroniczne.Mogą to być również spotkania grupowe, podczas których przeprowadza się kod.Okazuje się, że grupa może być bardziej produktywna, ponieważ różni ludzie łapią różne rzeczy.
ChrisW
2018-11-20 20:33:52 UTC
view on stackexchange narkive permalink

Ktoś musi zdefiniować „proces”, np. kolejność, w jakiej rzeczy się dzieją.

Jako programista, jeśli to nie ja definiuję proces, dokonam przeglądu kodu (jeśli to moja praca, zgodnie z oczekiwaniami mojego menedżera), gdy proces nakazuje mi i / lub gdy ktoś mnie o to prosi.

Nie rozumiem fragmentu pytania, który mówi: „odrzuciłem wszystkie nasze zaproszenia na spotkania przeglądu kodu w tym miesiącu”.

Nawiasem mówiąc, nie jestem pewien, co to jest „spotkanie przeglądu kodu”. Mój pomysł na przegląd kodu to:

  1. Ktoś go koduje
  2. Przeglądam (w swoim czasie) i robię notatki
  3. Spotykam się z programistę, aby omówić moją recenzję.

Jeśli jestem „starszy”, być może nie słucham spotkań innych osób poświęconych przeglądowi.

Aby zaoszczędzić czas (zmniejsz mój wysiłek) lubię przeglądać kod po przetestowaniu. Nadal mogę znaleźć błędy (np. Jeśli testowanie nie jest całkowicie zakończone), ale łatwiej jest przejrzeć kod, który działa, niż kod, który nie działa. Sprawdzanie kodu, który nie działa, nazywa się „programowaniem i debugowaniem” i jest bardziej czasochłonne.

Czy możesz uczynić „testowanie integracji” łatwiejszym, a może bardziej zautomatyzowanym? Abyś mógł:

  • Programowanie
  • Testowanie integracji
  • Recenzja
  • Popraw komentarze do recenzji
  • Ponowne testowanie integracji

Alternatywnie możesz scalić przed przeglądem kodu (jeśli ufasz, że testy integracji były wystarczające bez przeglądu), przeprowadź przegląd kodu w głównej gałęzi i użyj komentarzy przeglądu kodu jako dane wejściowe dotyczące tego, co chciałbyś poprawić w kolejnej iteracji (kolejnym „sprincie”).

-1 dla „przeglądu kodu należy wykonać po przetestowaniu”.Niektóre testy można zautomatyzować, ale wiele z nich jest wykonywanych ręcznie (dotyczy to zwłaszcza kodu frontendu, ale może być również prawdziwe w przypadku kodu zaplecza).Testowanie ręczne może zająć dużo czasu;przeglądy kodu są zazwyczaj krótkie.
Przez „po testach” rozumiem co najmniej po ponownym uruchomieniu [automatycznych testów dymu] (https://en.wikipedia.org/wiki/Smoke_testing_ (oprogramowanie)) oraz wszystko, co zrobisz, aby sprawdzić, czy nowa funkcja działa zgodnie z opisem.Różne systemy mają różny stopień automatyzacji w swoich testach (a powiedziałem, że gdyby ich testowanie było bardziej zautomatyzowane, mogliby sobie pozwolić na to częściej).
Testowanie w fazie rozwoju różni się od testowania w ramach przygotowań do wydania iw zależności od testów może zająć dużo czasu, dlatego warto ograniczyć częstotliwość ich uruchamiania.
@JoeW Tak, a „noc przed wielkim wydawnictwem” brzmi raczej [za] późno.Wydaje mi się, że „opinie wahały się od nieco pomocnych do nieco nieprzydatnych”, co oznacza, że nie znalazł on żadnych przeszkód, więc OP miał rację, aby opublikować je na czas.I to nie wszystko jest złe - fakt, że przegląd kodu nie znajduje przeszkód, niekoniecznie jest zły.Jaka * jest * jego praca, jeśli nie „uczyć moich inżynierów”?Czy ma po prostu przyjrzeć się (tj. Wypalić) zmianom w gałęzi integracji przed wydaniem?
@ChrisW Zdecydowanie zgadzam się, że niesprawdzony kod nie powinien być przeglądany (poszedłbym o krok dalej i powiedziałbym, że w ogóle nie powinien być popełniony!).Jednak, jak powiedział Joe, testy, których programista powinien wykonać w odniesieniu do swojego kodu, różnią się od testów, które przeprowadziłby QA.Ten pierwszy, oczywiście.Ta ostatnia nie tak bardzo.
Myślę, że przeoczyłeś krytyczny problem z jakimkolwiek testowaniem przed sprawdzeniem samego kodu.Jeśli testy integracji / testów dymnych będą wymagały znacznej ilości czasu do uruchomienia, czy sensowne będzie uruchomienie testów, a następnie wzajemna weryfikacja, która może znaleźć problemy wymagające ponownego wykonania testów?Czy nie miałoby sensu wykonanie przeglądu przed rozpoczęciem testów, aby można było znaleźć potencjalne problemy przed rozpoczęciem testów, aby zminimalizować częstotliwość wykonywania tych testów?
@JoeW Przypuszczam, że masz rację, tzn. OP sugerował, że jego „testy integracyjne” były kosztowne lub czasochłonne - więc może „proces” powinien określać, że kontrola powinna zostać przeprowadzona przed testami integracyjnymi?Jeśli dzieje się to przed testami integracyjnymi, to przed czy po integracji (nie wiem)?Może próbowałem znaleźć wymówkę dla Clive'a, tj. Zgadnąć, jakie mogą być motywy Clive'a.Jeśli chce zrewidować tak późno, może jego inspekcja powinna zostać potraktowana jako część testu integracji, tj. Po prostu „idź / nie idź”, a wszystkie jego częściowo pomocne komentarze w stylu odrzucone ...
... lub triaged, np.OP mógłby opcjonalnie dodać je do wytycznych przeglądu kodu swojego zespołu lub użyć ich do szkolenia w zakresie przeglądu kodu.
„Sprawdzanie kodu, który nie działa, nazywa się„ programowaniem i debugowaniem ”i jest bardziej czasochłonne”.Myślę, że jest to bardziej kompromis i może zależeć od umiejętności / doświadczenia programistów.Przeglądanie danych przed testami QA może ogólnie zaoszczędzić, jeśli znajdziesz poważne problemy, które oznaczają w dużej mierze przebudowę pracy;nie ma sensu testowanie kodu, który trzeba by w dużej mierze wyrzucić (np. dowiadujesz się, że jakiś kod pobierający kilka tysięcy wyników raportu przechwytuje powiązane dane po jednym rekordzie na raz).Staram się nie szukać rzeczywistych błędów, ale zamiast tego skupiam się na takich rzeczach, jak ogólne podejście i normy.
Aleksandr Dubinsky
2018-11-22 06:22:43 UTC
view on stackexchange narkive permalink

Jestem całkiem pewien, że ten facet właśnie ci mówi, że wykonujesz złą robotę. To właśnie oznacza „nie moim zadaniem jest uczyć inżynierów”. Nie jest zainteresowany wykonywaniem dla ciebie swojej pracy, chce, żebyś robił to lepiej. Dlatego przejrzał kod przeznaczony do produkcji (kod, na którym się podpisałeś), a nie kod w toku. A co z tym zrobić, to temat na inne pytanie.

Szczerze myślę, że to trafia w sedno.Większość osób spoza Twojego zespołu nie chce od niego dodatkowej pracy.Chcą tylko, aby Twój zespół wykonał dobrą pracę, więc nie muszą już o tym myśleć.
Zgadzam się, że to prawdopodobny scenariusz.Odkąd „Clint” pracował dłużej nad bazą kodów, prawdopodobnie też zna ją lepiej.
Joshua
2018-11-21 02:43:07 UTC
view on stackexchange narkive permalink

Uwaga.

✓ Starszy programista
✓ Znajduje problemy w kodzie, którego nikt inny nie zrobił
✓ Zespół zniechęcony z powodu późnego zgłaszania
✓ Zgłasza coś o „nie jego pracy” ale sprawdzone i tak
✗ przygotowuje się do powtórzenia tego samego scenariusza

Nie wygląda to zbyt dobrze ani dla zespołu, ani dla starszego programisty.

Ale mówię ci, uważaj. Upewnij się, że rozumiesz wszystkie komentarze w tej recenzji ściągania. I naprawdę rozumiem. - Ten jest po prostu zły. nie liczy się, chyba że naprawdę włożyłeś wysiłek w sprawdzenie.

Prawdopodobnie nie ma nic poważniejszego, co może być dla Ciebie destrukcyjne. Ale może istnieć niezwykle subtelny błąd utraty danych, który znalazł, a którego nie można ujawnić podczas testów. Nie poznasz różnicy, dopóki nie zrozumiesz wszystkich komentarzy.

Dodatek: Aby przywrócić morale zespołu, upewnij się, że masz wystarczająco dużo czasu na naprawienie wszystkich problemów, które starszy programista znalazł w żądaniu ściągnięcia, które reszta zespołu zgodzi się, że powinno zostać naprawione.

Joe W
2018-11-21 01:42:39 UTC
view on stackexchange narkive permalink

Problem polega na tym, że proces przepływu pracy jest wadliwy. Recenzje partnerskie powinny mieć miejsce przed testami integracyjnymi, ponieważ po prostu czekanie do zakończenia testów może spowolnić cały proces. Jeśli podczas wzajemnej weryfikacji wykryto problemy wymagające zmian, a testy integracyjne zostały już wykonane, potrzeba więcej czasu, aby cofnąć się i powtórzyć wszystkie testy po wprowadzeniu zmian.

Idealnie byłoby, gdyby programista napisał i przeprowadził testy gdy opracowują kod, a wszelkie końcowe testy powinny być wykonywane po weryfikacji kodu, aby upewnić się, że działa zgodnie z oczekiwaniami. Należy pamiętać, że wzajemna weryfikacja może wykryć błędy w kodzie, zanim będą one mogły wyłączyć system podczas testów integracyjnych.

„Problem polega na tym, że proces przepływu pracy jest wadliwy”.Nie rozumiem tej perspektywy.Wydaje mi się, że zespół stara się robić wzajemne recenzje wcześnie, a problem polega na tym, że Clint ignoruje je do ostatniej chwili.Proces przepływu pracy wydaje się w porządku, ale wydaje się, że Clint odmawia skutecznego udziału.
@DarthFennec Dlaczego miałbyś chcieć przeprowadzić testy integracyjne przed dokonaniem wzajemnej oceny kodu?Wydaje mi się, że jest to wadliwe, ponieważ będziesz musiał powtórzyć wszystkie testy, które zostały wykonane, jeśli zostanie znaleziony problem z kodem w recenzji.
Nie zgadzam się z tym.Mówię, że OP też się nie zgadza.„Następnego dnia zapytałem, czy mógł przejrzeć ten kod wcześniej, zamiast czekać do zakończenia testów integracji”.Wygląda na to, że OP i jego zespół próbują przeprowadzić wzajemną recenzję przed testami integracyjnymi, a stwierdzonym problemem jest to, że recenzent (Clint) działa przeciwko temu procesowi przepływu pracy.
@DarthFennec Częścią problemu jest tutaj brak szczegółów w pierwotnym pytaniu, co pozwala nam odczytać bardzo różne podstawowe narracje w historii.Twoja ocena, jak sądzę, jest taka, że zespół chciał, aby Clint przejrzał, ale uchylał się od swoich obowiązków do ostatniej minuty.Czytałem, że Clint nie był zaangażowany w projekt i nie miał nad nim władzy, a potem wpadł w zasadzkę w dniu ostatecznego terminu z gigantycznym PR zawierającym wiele miesięcy gównianego kodu, którego nie miał wcześniej szansy przejrzeć, a potemOP zirytował się „późną” informacją zwrotną i połączył ją z zastrzeżeniami Clinta.
@MarkAmery „wpadł w zasadzkę w dniu ostatecznego terminu” czy to nie wydaje się być sprzeczne z zachowaniem OP?Dlaczego OP miałby powiedzieć „Zapytałem, czy mógł przejrzeć ten kod wcześniej, zamiast czekać do zakończenia testów integracyjnych”, jeśli Clint wpadł w zasadzkę z kodem po testach integracji?Dlaczego odpowiedź Clinta brzmiałaby „to nie moja praca” zamiast „Nie wiedziałem o tym przed testami integracyjnymi”?Nie mówię, że się mylisz, po prostu nie rozumiem, jak doszedłeś do swoich wniosków.Zgadzam się jednak, że byłoby lepiej, gdyby OP mówił o tym bardziej jasno.
@DarthFennec Zgadzam się, że postawa PO wydaje się irracjonalna, biorąc pod uwagę moją interpretację, ale potwierdza ją edycja OP.Sekwencja wydarzeń jest następująca: 1. część zmian, w których Clint nie ma żadnej roli, zostanie wykonana przez zespół OP, 2. zostanie otwarty PR wydania, 3. Clint zostaje poddany kontroli poczytalności i robi to tego samego dniapewne negatywne opinie, 4. wydanie i tak następuje następnego dnia o 4:30, 5. OP skarży się Clintowi na „późną” informację zwrotną.Komentarz „To nie moja praca” wydaje się rozsądny ze strony kogoś, kto wykroczył poza obowiązek pozostawienia obszernej opinii członkom ...
@DarthFennec ... inny zespół programistów, a następnie został skrytykowany za to i powiedział, że powinni byli zrobić więcej i wcześniej, nad projektem, który nie był ich początkiem.Odpowiedź PO na to wydaje się po prostu drobnym przerzuceniem winy bez większego uzasadnienia - co jest przynajmniej czymś ludzkim i zrozumiałym.
@MarkAmery Z edycji: „otwieramy PR, aby połączyć się z Master ** po zatwierdzeniu zmian przez ** enga”. Interpretowałem to tak, aby oznaczało, że Clint był jednym z tych inżynierów i czekał z zatwierdzeniem zmian do czasu PR, abyMaster został stworzony, zamiast robić to przed lub równolegle z testami integracyjnymi QA, tak jak powinien.Ale to naprawdę może się udać.Fakt, że OP był wielokrotnie pytany o rolę Clinta i nie odpowiadał bezpośrednio, że w edycji jest podejrzany;jeśli celowo omija to pytanie, uwiarygodnia to obarczającą winę interpretację.
@MarkAmery Nic nie wskazuje na to, że wkład Clinta był wymagany.(Rzeczywiście, wdrożenie miało miejsce, zanim można było rozważyć jego komentarze.) OP zaprasza Clinta do recenzji kodu i obawia się, że komentarze z ostatniej chwili, które nie mogą być przydatne dla tego wydania, pojawią się ponownie.OP najwyraźniej chce, aby Clint pomógł w edukacji swojego zespołu, i oczywiście Clint nie chce tego robić.Każde oskarżenie o przerzucanie winy naprawdę powinno pokazać, że wina istnieje w pierwszej kolejności, a ja tego nie widzę.
Karl Bielefeldt
2018-11-21 20:49:41 UTC
view on stackexchange narkive permalink

Masz dwa różne rodzaje recenzji (trzy, jeśli liczyć osobiste spotkanie). Nie jest to z natury złe, ale oznacza, że ​​musisz bardzo jasno określić swoje oczekiwania w każdej sytuacji. Utworzyłbym szablon żądania ściągnięcia do ostatecznej oceny, który wyglądałby mniej więcej tak. Dzięki temu jest bardzo jasne nie tylko, czego oczekuje się od tej recenzji, ale także jak sprawić, by Twoja opinia była skuteczniejsza w przyszłości.

< Podsumowanie zmian>

przegląd przedprodukcyjny. Jego celem jest znalezienie głównych problemów, takich jak:

  • Łączenie błędów
  • Przypadkowe dołączenie niepełnej funkcji
  • Błędy Showstopper

O ile nie wystąpią tego rodzaju problemy, to żądanie ściągnięcia zostanie połączone w <date i time>.

Indywidualne przeglądy projektu, w których omawiamy czytelność, łatwość utrzymania i ogólną architekturę, zostały już zakończone. Jeśli znajdziesz tutaj tego rodzaju problemy, otwórz problem lub wprowadź zmiany we własnym żądaniu ściągnięcia do programowania, zamiast zaśmiecać to żądanie ściągnięcia. Recenzje projektu zostały przeprowadzone w następujących żądaniach ściągnięcia:

  • <Link do PR 1>
  • <Link do PR 2>


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...