Pytanie:
Jak mogę skłonić współpracowników do przejrzenia mojego kodu?
deutsch-koder
2020-03-05 18:20:49 UTC
view on stackexchange narkive permalink

Kontekst: moja produktywność jako programisty jest związana z dostarczaniem mojej pracy, a dostarczanie mojej pracy wiąże się z sprawdzeniem i zatwierdzeniem mojego kodu przez współpracowników.

Ale ostatnio byłem mając problem ze skłonieniem współpracowników do rozpoczęcia przeglądu kodu. W przypadku łatwych (jednowierszowych zmian) zajęłoby to kilka godzin, co jest w porządku, ale miałem krytyczne zadania, które uniemożliwiłyby innym zajęcie wielu tygodni. Nigdy nie jest zbyt duży ani szczególnie trudny do przejrzenia - byłoby zepsute cokolwiek ponad 300 linii.

To drugi raz w mojej karierze.

W poprzedniej firmie , Menedżer musiałby od czasu do czasu interweniować. Kiedyś połączył wszystkie moje pull requesty, które były otwarte przez ponad dwa tygodnie, ponieważ reszta zespołu nie przeglądała mojej pracy.

Rutynowo staram się nadać priorytet przeglądaniu kodu innych osób i ' Według naszych raportów jestem zawsze najlepszym recenzentem w moim zespole ... zarówno pod względem czasu, jak i ilości recenzji / ilości sprawdzonych linii kodu. Jeśli chodzi o juniorzy, to staram się nie być zbyt twardym lub zbyt poważnym, zawsze przekazuję zarówno pozytywne opinie, jak i negatywne, i zawsze staram się nie zostawiać zbyt wielu komentarzy ...

W obu zespołach byłem jednym z najstarszych członków i nigdy nie miałem złych opinii na temat jakości mojego kodu. W jednym z zespołów byłem „facetem od jakości kodu”.

Czy to ja mam problem? Mam przyjacielskie relacje z moimi współpracownikami i spędzam z nimi czas poza biurem, a poza tym nigdy nie miałem kłótni ani nic w tym rodzaju, i dokładam wszelkich starań, aby nie wyglądać na bezczelnego lub zarozumiałego. Rzadko powoduję błędy, a kiedy już to robię, przerywam wszystko, co robię, aby je naprawić lub pomóc drugiej osobie.

Menedżerowie mnie komplementują, co jest dziwne, ponieważ czuję, że istnieje przepaść między ja i reszta zespołu.

To sprawiło, że poczułem, że ja i mój kod jesteśmy głęboko niechciani przez zespół.

Czy jest na to jakieś rozwiązanie? Czy to wszystko w mojej głowie?

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/105280/discussion-on-question-by-deutsch-koder-how-can-i-get-my-coworkers-to-recenzja-moja).
Czy zastanawiałeś się nad poproszeniem swojego kierownika, aby zapłacił freelancerowi za przegląd Twojego kodu?Mógłbym nawet zostać tym freelancerem (wyślij mi e-mail na adres `[email protected]` i spójrz na [moje CV] (http://starynkevitch.net/Basile/cv-Basile-Starynkevitch.pdf))
Czy wyróżniasz się „przed” swoim zespołem?Jeśli tak, niektóre zespoły reagują źle, nawet jeśli nie było to Twoim zamiarem.Chociaż wiele osób twierdzi, że „prawdopodobnie myślą, że ich nie potrzebujesz / prawdopodobnie boją się recenzji”, istnieje inny możliwy powód.To cię spowalnia.
@Bohemian To dobra strategia.Menedżer faktycznie zgadza się z twoją sugestią.
Czternaście odpowiedzi:
#1
+93
Arthur Hv
2020-03-05 18:56:02 UTC
view on stackexchange narkive permalink

Zauważyłem w Twoim poście rzeczy, które mogą być powiązane z tą sytuacją:

  • Jesteś najlepszym recenzentem swojego zespołu
  • Jesteś również jednym z najstarszych członek
  • Twoja indywidualna produktywność jest monitorowana na podstawie wyprodukowanego kodu

Dlatego

  • Twój zespół może zapomnieć, że musi wykonać kod recenzje, ponieważ robisz ich tak dużo
  • Twój zespół może pomyśleć, że nie ma umiejętności niezbędnych do „osądzania” Ciebie
  • Twój zespół może myśleć, że musi się skupić lub ustalić priorytety zamiast tego produkują swój kod.

Nie powinieneś bać się prosić współpracowników o przejrzenie iz potencjalnego powodu nie sprawdzają Twojego kodu. Moje podejście polegałoby na rozmowie z kolegami z małej komisji lub 1 na 1, ponieważ wydaje mi się, że tam byłoby łatwiej być szczerym, ale możesz też zacząć pytać na spotkaniach np. retrospektywy i tym podobne. Ponieważ masz wskaźniki, możesz zapytać osoby, które dokonują najmniej recenzji, i zapewnić, że jest to zarówno łatwe, jak i doceniane.

W końcu, po kilkukrotnym zapytaniu ludzi, nabiorą oni dobrych nawyków w przeglądaniu recenzji i recenzowaniu rzeczy samodzielnie. Często pingujemy się na czacie w poszukiwaniu oczekujących recenzji, a obciążenie jest teraz dość zrównoważone.

_ „Twój zespół może pomyśleć, że nie ma umiejętności potrzebnych do" osądzania "ciebie" _ Dokładnie w tym punkcie próbowałem napisać odpowiedź, więc zamiast tego +1.
Pierwsza kwestia jest dobra.Ponieważ OP zawsze jest szybkim recenzentem, innym programistom łatwo jest zobaczyć „o, hej, ktoś już to sprawdził, nie muszę” i wpadnie w „Nie muszę recenzować, ktoś inny to zrobito "sposób myślenia.Najlepszą rzeczą do zrobienia jest przypisywanie recenzji, a nie tylko ogólnych otwartych żądań, aby pojawiały się one jako część zwykłych zadań wszystkich (i można je śledzić, aby menedżerowie mogli zobaczyć, kto ich nie wykonuje).
Przypomnij im również, że przegląd kodu jest dla nich dobrą okazją do nauczenia się od Ciebie, a każde pytanie jest pomocne.Zrób to w sposób, który nie wydaje się protekcjonalny, na przykład dodaj „to jeden z powodów, dla których robię tak wiele recenzji” (co najprawdopodobniej jest prawdą)
Moja pierwsza opinia dla każdego, kto organizuje procesy tego zespołu, byłaby również taka, że proces daje niewłaściwe bodźce, oceniając ludzi według ich zaimplementowanych funkcji.Jeśli czujesz, że potrzebujesz takiej oceny (a ja zwykle gardzę czymś takim), przynajmniej upewnij się, że wszystkie istotne części, które ktoś musi wykonać, są faktycznie częścią twojego wskaźnika!To znaczy.Twoje recenzje również muszą się liczyć.Byłoby to przyjemnie „hazardowe”: funkcja liczy się do Twoich „punktów” tylko wtedy, gdy istnieje recenzja, która „odblokowuje ten automat”.
„Twój zespół może pomyśleć, że nie ma umiejętności niezbędnych do„ osądzania ”Ciebie”.Przypomnij kolegom z zespołu: to kod jest oceniany, a nie koder.
„Ukończone przeglądy kodu” byłyby mierzalnym i śledzonym wskaźnikiem, prawdopodobnie również w tym przypadku bardzo by pomogło.Jeśli wszyscy są śledzeni pod kątem ich produktywności, a recenzje kodu nie znajdują się na tej liście, to każdy ma motywację do robienia wszystkiego innego niż przeglądy kodu.
Jedna mała uwaga: przeglądanie kodu to _umiejętność_.Jeśli robisz mnóstwo recenzji kodu innych osób, czy ktoś inny ma szansę zbudować tę umiejętność?Na przykład, czy wszyscy juniorzy mogą przeglądać swój kod - czy też jesteś główną osobą, która to robi?Dodatkowo, czy jest jakikolwiek mentoring prowadzony przez Ciebie lub inne osoby starsze _ dotyczące przeprowadzania dobrych recenzji kodu_?Słuszne pytanie - nie sądzę, aby było to jednoetapowe rozwiązanie.
#2
+23
Paŭlo Ebermann
2020-03-06 06:57:22 UTC
view on stackexchange narkive permalink

Myślę, że problem polega na tym, że od każdego członka zespołu oczekuje się wykonania własnej pracy zamiast wspólnego celu, jakim jest dostarczenie.

Jeśli każdy inżynier ma własny fragment kodu do napisania i dostarczenia , i jest mierzony na podstawie osiągnięcia tego (a nie osiągnięcia celu zespołowego), to oczywiście nie ma zachęty do przeglądania zmian w kodzie innych osób.

Nie jestem pewien, co Ty jako jedna osoba możesz zrobić, aby to zmienić - należy do tego podejść z punktu organizacyjnego (tj. od przełożonego, właściciela produktu itp.). Zespół musi mieć jasne priorytety dotyczące tego, co jest najważniejsze, a wtedy te elementy dostawy będą musiały przejrzeć przed rozpoczęciem pracy nad innym kodem.

Zawsze możesz przekazać opinię i rozpocząć dyskusję.Często okaże się, że inni do pewnego stopnia podzielają twoje zdanie, jeśli proces jest wadliwy.Po prostu mogą sobie z tym poradzić inaczej.OP może również ograniczyć dokonywanie recenzji, więc cały zespół widzi, że w jakiś sposób wszyscy muszą uzgodnić, jak najlepiej rozłożyć to obciążenie pracą, ponieważ wszyscy będą cierpieć, gdy nikt ich nie zrobi.Ale ogólnie rzecz biorąc, wydaje się, że jest to w dużej mierze problem zespołu i wszystkich dla siebie.
#3
+18
JayZ
2020-03-05 18:49:00 UTC
view on stackexchange narkive permalink

Idź do biurek swoich współpracowników i zapytaj ich, czy są dostępni do przeglądu kodu. W przypadku krótkich najprawdopodobniej się zgodzą, w przypadku dłuższych mogą poprosić o zrobienie tego później, skorzystaj z okazji, aby określić przedział czasowy dla twojej recenzji.

Jeśli naprawdę tego potrzebujesz, możesz formalnie założyć spotkanie, może być przydatne zarówno do zapewnienia przeglądu kodu, jak i do uniknięcia przeszkadzania Tobie lub Tobie recenzentowi przez inne osoby.

Poproś kogoś konkretnego o przejrzenie, tak.Ale nie idź do ich biurka, chyba że (1) musisz sparować podczas recenzowania (recenzje zwykle można zrobić samodzielnie), (2) już próbowałeś zadać im pytanie za pomocą GitHub, komunikatora internetowego lub w trybie stand-up lub (3) ty 'konkretnie próbują ich zirytować lub stanąć po ich złej stronie.
Wiem o co ci chodzi.Wolę robić przegląd w parach, ponieważ pozwala to na dyskusję i zapobiega przechodzeniu do przodu i do tyłu przez narzędzie, gdy pojawiają się pytania lub sugestie ulepszeń.
Mamy codzienne stand-upy i jedną z rzeczy, które na nich robimy, jest sprawdzanie listy oczekujących żądań ściągnięcia.W każdym razie osobiste pytanie współpracownika (w biurze lub za pomocą komunikatora) jest dość powszechne, gdy chcemy szybko dostarczyć funkcję.Dobrze jest też, gdy ludzie dodają tylko odpowiednie osoby zatwierdzające do ściągania żądań, w przeciwnym razie osoby zatwierdzające zaczną je ignorować.
#4
+7
JRodge01
2020-03-05 18:44:03 UTC
view on stackexchange narkive permalink

Po pierwsze, nie internalizuj braku przeglądu kodu jako problemu, który ma z Tobą Twój zespół. Wygląda na to, że myślisz, że brak przeglądu kodu jest dla ciebie osobistą krzywdą, co prawdopodobnie nie jest prawdą. Czasami ludzie są zajęci lub nie widzą korzyści z przeglądania kodu. To nie jest atak.

Po drugie, jeśli widzisz potrzebę przeglądu kodu, a zespół nie poświęca czasu, porozmawiaj ze swoim przełożonym. Kilka miejsc, w których pracowałem, miało ustalony czas każdego tygodnia na przeglądy kodu i wyeliminowaliśmy kilka bardziej krytycznych recenzji jako zespół w przypadku większych lub bardziej priorytetowych zmian. Mniejsze mogliśmy przeglądać w parach, zgodnie z naszymi harmonogramami. Ale nigdy nie pozwalaliśmy na scalanie kodu bez przeglądu.

Porozmawiaj ze swoim przełożonym o ustaleniu rytmu przeglądu kodu, który będzie działał dla Twojego zespołu, i bądź otwarty, że kierownik może nie postrzegać tego jako ważnej zmiany w wprowadzić w życie. Dla niektórych menedżerów przegląd kodu nie jest ważny, dopóki nie zobaczą, jak może poprawić wyniki finansowe.

#5
+7
Alex L
2020-03-05 19:10:44 UTC
view on stackexchange narkive permalink

To nie ty, problemem jest kultura zespołowa. Pomijając przeglądy kodu, zespół nie przestrzega praktyk inżynierii oprogramowania i nie rozumie, dlaczego są one ważne. Jest to krytyczny problem, który wymaga natychmiastowej zmiany. Należy zająć się tymi kwestiami:

  • Dlaczego jest to ważne.
  • Dla kogo? i kto powinien to zrobić? Chciałbym wyjaśnić, że przegląd kodu powinien być dokonywany nie tylko przez seniorów, a seniorzy również potrzebują przeglądu swojego kodu. Widziałem zespoły, które wprowadziły zasady egzekwowania git, takie jak chroniona gałąź, która wymaga dwóch recenzentów.
  • Jak przeglądać kod i jak udzielać odpowiednich opinii.

Oczekiwania powinny być takie jasny. Punkty te należy przedstawić zespołowi (np. Spotkanie, obiad & learn). Zmiana jest trudna, bądź przygotowany i szukaj sojuszników.

Uważam, że jest to już całkiem jasne dla zespołu, biorąc pod uwagę, że przeglądy kodu są już wymagane do scalenia czegokolwiek w całej organizacji.
Zespół @deutsch-koder może wiedzieć, że jest „potrzebny”, ale może nie mieć motywacji, aby to zrobić.Częściowo może to być spowodowane tym, że nie widzą sensu w wymaganiu.Ogólnie lub dlatego, że są niesłusznie zmotywowani, aby nie przejmować się nimi, ponieważ nie są częścią ich oceny wyników.Chociaż nie zgadzam się z „przedstawieniem” im tego, jak to wszystko jest (co może wydawać się protekcjonalne), może zaistnieć potrzeba dyskusji, jak chcesz właściwie sobie z nimi poradzić, jaki powinien być Twój proces, jak wizualizujeszto i możesz chcieć zmienić motywację.
#6
+4
kutschkem
2020-03-06 14:06:08 UTC
view on stackexchange narkive permalink

Udało mi się wyraźnie wyznaczyć kogoś do recenzji. W naszym obecnym projekcie posunęliśmy się nawet do ponownego przypisania problemu w JIRA recenzentowi. Jeśli nie możesz tego przypisać innej osobie, przydziel to osobie, która może (kierownikowi projektu). Nie ma znaczenia, że ​​ta osoba faktycznie dokonuje przeglądu, ważne jest, aby dana osoba zadbała o to, aby przegląd została wykonana.

Przypisanie konkretnej osoby oznacza, że ​​jest to teraz, w sposób identyfikowalny, zadanie do wykonania tej osoby. Uważam, że nawet dla mnie, który i tak robi większość recenzji, pomocne jest przydzielenie mi zadań przeglądu - to jasno pokazuje, że zadanie jest w stanie przeglądu i że postęp jest teraz przeze mnie blokowany / że jestem odpowiedzialny teraz.

To, absolutnie to - „Jeśli to problem wszystkich, to nie jest to żaden problem”.Kiedy przypisujesz to komuś, robisz to za jego odpowiedzialność i coś, co można wywołać w codziennej walce, jeśli tego nie wypełnia.
jawnie -> jawnie
@FaheemMitha Dzięki, naprawione
#7
+4
takacsmark
2020-03-06 15:48:30 UTC
view on stackexchange narkive permalink

Byłem w bardzo podobnej sytuacji. Dobry facet, komplementy menedżerów, skrupulatna dbałość o dostawę, dobre relacje z ludźmi poza pracą.

Na mojej liście priorytetów było bycie świetnym wykonawcą. Pewnego dnia nowy facet w moim zespole powiedział mi, że słyszał, że jestem dziwką, ale wszyscy mnie kochają. Szczere opinie 360 ​​stopni. :)

Wtedy zdałem sobie sprawę, że miałem taką obsesję na punkcie perfekcji, że ludzie byli moim drugim priorytetem. Wciąż był to wysoki priorytet. Zrobiłem wszystko, co w mojej mocy, dla ludzi, z wyjątkiem poświęcenia jakości.

Ludzie to czują. Nawet jeśli nie jest to z mojej strony świadome, szedłem wysoko, jakby jakość była moim drugim imieniem. Zdałem sobie sprawę, że to sprawia, że ​​ludzie czują się drugorzędni lub gorsi.

Od razu stawiam ludzi na pierwszym miejscu, ponieważ i tak był to mój zamiar, po prostu nie widziałem, że mnie tam nie ma Życie bardzo się poprawiło, ludzie zdobyli wiele nowych umiejętności, zespół stał się świetny, jakość była mocna i stabilna.

Może to nie mieć zastosowania w Twojej sytuacji, po prostu zostawiam to tutaj, może to pomaga.

Byłem taki jak ty.Ból karku, który ludzie doceniali, robiąc recenzje.W przypadku kodu, który naprawdę znałem, w dużej recenzji znajdę dziesiątki problemów, których nikt inny nie zauważy (kiedy poszedłem ostatnio celowo).Sztuczka polega na tym, aby pamiętać o kwestionowaniu „naszego kodu”, a nie „Twojego kodu” lub „Ciebie”.W ten sposób idzie o wiele lepiej.
Co tak naprawdę wymagało przeniesienia twojego priorytetu z jakości na ludzi?pod względem zachowania?
Najpierw wykorzystałem metody, które stosujemy w szkole, aby odnieść sukces indywidualnie.Ale to nie działało z zespołem.Zachowywałem się jak nauczyciel, co powodowało wiele tarć, nie czułem się dobrze i nie było to produktywne.Magia ma miejsce, gdzie wzmacnianie ludzi.Zupełnie inny wszechświat i czuję się świetnie.Pomóż innym osiągnąć sukces na ich drodze, a zespół rozkwitnie.:)
Czy mógłbyś wyjaśnić różnicę między „działaniem jako nauczyciel” a „wzmacnianiem pozycji ludzi”?
#8
+3
Lawnmower Man
2020-03-07 03:16:02 UTC
view on stackexchange narkive permalink

Consensus

Nie możesz skłonić członków zespołu do przejrzenia kodu, jeśli zespół nie zgadza się, że przeglądy kodu są cenne. Powiedziałbym, że przegląd kodu jest jedną z trzech rzeczy, których większość programistów nie robi wystarczająco dużo. Więc pierwszym krokiem jest po prostu porozmawianie o przeglądzie kodu na spotkaniu z całym zespołem (w tym menedżerami). Zapytaj ich, co o tym myślą, czy jest to wartościowe i jak często należy to robić.

Założę się, że co najmniej połowa z nich uważa, że ​​to strata czasu. Jeśli tak, pierwszym krokiem jest edukacja. Musisz wyciągnąć recenzje, w których zamieszczono cenne komentarze, zwłaszcza jeśli ktoś złapał rzeczywisty błąd przed scaleniem (nie powinieneś sprzedawać CR jako narzędzia do wyszukiwania błędów, ale jest to miły bonus, gdy to się stanie). Jeśli Twoi współpracownicy nie mają doświadczenia, może to być trudna sprzedaż. Mimo to powinieneś delikatnie podnosić to tak często, jak to możliwe, aby w końcu przyswoili sobie ideę, że CR -> lepsza jakość -> lepszy kod -> mniej błędów -> lepsza jakość życia dla programistów.

Egzekwowanie

Gdy zespół przynajmniej przyzna się, że CR jest wartościowy, musisz stworzyć mechanizm, który będzie go egzekwował. Idealnie, twój system kontroli wersji robi to (na przykład trywialne do skonfigurowania na GitHub). Jeśli nikt nie może się scalić bez otrzymania CR, to miejmy nadzieję, że każdy ma na niej wąskie gardło i tym samym jest zmotywowany do usuwania zaległości. Kiedy tak się stanie, musisz zrobić coś, co na pierwszy rzut oka może wydawać się dla ciebie nieskończenie trudne: nie musisz nic robić. Na jednego dewelopera przypada średnia liczba PR, dlatego każdy programista musi wykonać taką liczbę CR, aby mieć równy rozkład pracy. Musisz oszacować tę liczbę i zrobić nie więcej niż tyle CR.

Wkrótce wszyscy w zespole będą narzekać, że istnieje olbrzymia liczba zaległości w PR czekających na połączenie, i musisz jasno powiedzieć, że cały zespół musi ponieść ciężar ich przeglądu. Delikatnie przypomnij im, że uzgodnili wartość i opieraj się wszelkim wezwaniom do usunięcia blokady CR przy fuzjach. Najprawdopodobniej będą robić CR niechętnie i sporadycznie. Aby pomóc w przypisaniu odpowiedzialności, stworzyłem narzędzie dla mojego zespołu, które wykonywało bardzo podstawowe przydziały PR do programistów. Każdy mógł zobaczyć, kto nie robi recenzji, i wszyscy wiedzieli, z kim rozmawiać, jeśli ich PR został zablokowany. Samo posiadanie takiej widoczności pomaga wymusić pożądane zachowanie.

Poza tym staż ma niewiele wspólnego z tym zjawiskiem. Widzę to u programistów na wszystkich poziomach umiejętności. Wielokrotnie to młodsi programiści, którzy dorastali w bardziej nowoczesnej kulturze oprogramowania, przyjmują recenzje kodu, podczas gdy starsi programiści, którzy są przyzwyczajeni do łączenia się bez recenzji, opierają się temu. Tak naprawdę jest to tylko indywidualna preferencja, która niestety jest powszechna w całej branży.

Oczekiwania

Wreszcie, musisz zapomnieć o tym, że CR służą do znajdowania usterek. Przegląd kodu powinien dotyczyć przede wszystkim rozpowszechniania wiedzy. Samo przeczytanie Twojej zmiany przez kogoś innego sprawia, że ​​inna osoba w zespole jest świadoma zmiany i bardziej prawdopodobne, że zespół zauważy potencjalne konflikty projektowe z jednoczesnymi lub nieuchronnymi zmianami. To także dla edukacji. Młodsi deweloperzy powinni wyciągnąć tyle samo z wykonywania CR, co seniorzy, ale o innym charakterze. Powinieneś nauczyć juniorów, że jeśli nie mają krytyki na temat recenzowanego kodu, powinni zadawać pytania . Z pewnością uczą się czegoś nowego tu i tam lub widzą coś nieoczekiwanego, co zostało zrobione inaczej, niż by to zrobili. Zadanie tych pytań i uzyskanie dobrych odpowiedzi pomoże im dowiedzieć się, jakie praktyki są specyficzne dla Twojej firmy, w porównaniu z ogólnymi sprawdzonymi metodami inżynierii oprogramowania.

Jeśli ktoś niechętnie lub waha się przed przeprowadzeniem recenzji, szczególnie w odniesieniu do Twojego kodu, po prostu zaproponuj, że przeprowadzi z nim recenzję. Powiedz im, czego szukasz, i poproś o wyjaśnienie kodu. Jeśli w ich wyjaśnieniu brakuje czegoś interesującego, zadaj wiodące pytania, aby podkreślić swój punkt widzenia. Jeśli nie zrozumieją trochę do końca, poproś ich o zadanie pytania na temat recenzji, aby pokazać, że Twój kod nie dokumentował się tak samo, jak mógłby być. Następnie przejrzyj jeden z ich lub cudzych PR i zademonstruj te same zasady. Pokaż na przykładzie, że CR nie musi onieśmielać i że może być cennym doświadczeniem edukacyjnym dla każdego.

#9
+1
ObscureOwl
2020-03-06 15:48:58 UTC
view on stackexchange narkive permalink

Wspomniałeś w komentarzach, że pracujesz nad bardziej skomplikowanymi rzeczami niż reszta Twoich kolegów.

Wygląda to na podwójne niebezpieczeństwo: Twój kod nie jest sprawdzany, a inne osoby nie wiem, jak działa zaawansowany temat. Jeśli uderzył Cię autobus, zespół miałby kłopoty.

Ale to też może być punkt wyjścia do rozwiązania problemu. Porozmawiaj ze swoim przełożonym o tym, jak Twoim zdaniem powoduje to, że zespół jest podatny na zranienie, i poproś o wybranie 1-2 współpracowników, którzy zostaną „zainicjowani” w trudnych sprawach, które robisz. To sprawia, że ​​są logicznym wyborem do przeglądu twojego kodu, a także poprawia współczynnik magistrali.

Trafne spostrzeżenie.To dużo większy problem niż brak recenzji.Ale szczerze mówiąc, zajmuję się programowaniem eksploracyjnym i oczekuję od nich trochę wysiłku.Zawsze jestem gotowy, aby wyjaśnić różne rzeczy i postanowiłem powiedzieć wszystkim, że powinni „klepnąć mnie w ramię, nawet jeśli wyglądam na zajętego”.
Przy okazji poszedłem dalej i rozmawiałem z moim przełożonym, a on również zgadza się, że musimy dzielić się wiedzą.
#10
+1
Mike-314
2020-03-07 07:17:23 UTC
view on stackexchange narkive permalink

Wygląda na to, że problem dotyczy procesu i zarządzania. Po pierwsze, pracujesz w zespole, więc odnosisz sukcesy jako zespół i przegrywasz jako zespół. Jeśli dostawy nie są realizowane, oznacza to porażkę zespołu. W przeszłości, jeśli mieliśmy problemy z recenzjami kodu i testami wzajemnymi, a my jako zespół zawarliśmy umowy, aby uzgodnić, że wszystkie recenzje i testy wzajemne musiały zostać wykonane przed rozpoczęciem nowego zadania deweloperskiego, a każdy, kto przyłapano na łamaniu zasad, został wezwany na zewnątrz. Innym razem po prostu przydzielaliśmy te zadania w sposób okrężny. Ty, Twój zespół i Twój menedżer musicie rozwiązać ten problem razem, ale nigdy nie bójcie się zgłaszać problemu, zwłaszcza jeśli dostawy nie są realizowane. Bądź szczery, bezpośredni, ale bądź uprzejmy. Nie bój się też pytać ludzi o problem. Zdziwiłbyś się, w większości przypadków po prostu ci powiedzą.

#11
  0
Sinc
2020-03-07 00:52:27 UTC
view on stackexchange narkive permalink

To może nie być Ty, proces lub zajęcie. Może po prostu być tak, że wielu programistów nie lubi przeprowadzać inspekcji. Niektórzy w nich nie wierzą, niektórzy nie chcą tracić czasu, niektórzy wiedzą, że nie są w nich aż tak dobrzy.

Są ludzie tacy jak ty (i ja), którzy są bardzo chętni do poświęcenia przyzwoitej ilości czasu na prawidłowe sprawdzenie zmiany. Są powody, dla których to robimy. Nie mogę podać powodów, ale moje obejmują takie rzeczy, jak:
Sprawdzam lepiej niż większość projektantów, z którymi kiedykolwiek pracowałem,
pisuję i czytam lepiej niż większość, więc nawet Twoje komentarze zostaną poprawione,
Obawiam się, że inni ludzie dokonują złych zmian w systemie, które mogą mieć wpływ na mnie, a co gorsza na naszych klientów,
moja wczesna historia obejmowała organizowanie i przewodniczenie staromodnym inspekcjom grupowym, które dały mi niezwykle szeroki kontakt z nasz kod, więc doceniam wartość oglądania kodu innych osób.

Ucz się, chroń, zespołowo. Przydatne wartości płynące z uczestnictwa.

Prawdopodobnie wiesz, kim są inni najlepsi inspektorzy. Najprawdopodobniej podzielają twoje zainteresowanie inspekcją, przynajmniej trochę. Sprawdź, czy możesz dowiedzieć się, dlaczego to robią lub dlaczego są w tym dobrzy, i odwołać się do tych instynktów. „Wprowadziłem kilka zmian w tym podstępnym fragmencie kodu i potrzebuję kogoś dobrego, kto by to sprawdził”. Lub jeśli są tylko graczami zespołowymi „Muszę to sprawdzić w [określonym czasie]. Czy możesz mi pomóc?”

#12
  0
JustBrowsing
2020-03-07 01:05:00 UTC
view on stackexchange narkive permalink

Całkowicie zgadzam się z tym, co zostało powiedziane na temat niechęci do recenzowania skomplikowanych rzeczy i braku wyznaczenia kogoś do odpowiedzialności - a nie widziałem w Twoim pytaniu nic, co wskazywałoby, że Ty i Twój kod jesteście niechciani przez Twój zespół! Raczej myślę, że Twój zespół nie ma jasnych procedur dotyczących obsługi recenzji.

Dużo rozmawialiśmy o recenzjach w moim zespole. Może niektóre z naszych wniosków mogą być pomocne dla Ciebie i Twojego zespołu:

  • Czego oczekujemy od recenzji? Nie (przynajmniej przede wszystkim) szukamy drobnych szczegółów. Chcemy złapać pułapki i złe wybory architektoniczne i tym podobne. Chcemy również wymieniać się dobrymi pomysłami i ulepszeniami, które moglibyśmy dostrzec, ale to drugorzędne.
  • Ponieważ tego chcemy, wykonanie recenzji bez autora zajęłoby zbyt dużo czasu. Byłoby to jak przemyślenie wszystkich myśli autorów, ale bez zdobywania doświadczenia podczas tworzenia!
  • Nawet jeśli zatwierdzenie jest dość proste, nie musi być rozrzucone po bardzo wielu plikach, zanim trudno będzie ustalić, gdzie zacząć i gdzie zakończyć - zwłaszcza jeśli nie jest to „zwykłe obszar kodu ”
  • Jesteśmy doświadczonymi programistami i szczerze mówiąc, zwykle mamy całkiem dobre przeczucia co do tego, co jest obszarem niebezpiecznym i co jest prawdopodobnie trywialne w tym, co właśnie zrobiliśmy.
  • Recenzje to doskonała okazja do podzielenia się wiedzą!
  • Nasze rozwiązanie: autor musi poprosić co najmniej jednego kolegę z zespołu o przyjście na recenzję. Może to mieć miejsce przy biurku lub na spotkaniu, w zależności od zakresu. Autor musi przedstawić, co zrobili, jakie wybory i kompromisy zostały dokonane i dlaczego - a następnie koledzy z zespołu przekazują informację zwrotną. W ten sposób odpowiedzialność spoczywa na autorze, a recenzent nie musi sam wszystkiego rozumieć: ma go przedstawionego przez kogoś, kto ma przegląd i może odpowiedzieć na wszelkie pytania, które mogą pojawić się po drodze.

Dodam, że na poziomie osobistym jesteśmy bardzo dobrze funkcjonującym zespołem o dużym zaufaniu. Nie bierzemy informacji zwrotnej osobiście i przedstawiamy ją w pozytywny, rozbrajający sposób. Ponadto, jeśli pracujemy nad skomplikowanymi rzeczami, spieramy się i dyskutujemy po drodze. W ten sposób mamy koncepcyjny przegląd tego, nad czym pracują inni, nawet zanim będziemy musieli przejrzeć rzeczywisty kod.

Nawet jeśli Twój zespół nie wymyśli wspólnej strategii dotyczącej recenzji, możesz wziąć pomysły z tego, jeśli myślisz, że będą dla Ciebie pracować: spieraj się podczas tworzenia, zapraszaj kolegów z zespołu do recenzji, w których prezentujesz - i pamiętaj, aby powiedzieć im o wątpliwościach i kompromisach, które spotkałeś po drodze. Mogą być przez Ciebie trochę onieśmieleni, jeśli jesteś bardzo dobry, więc jeśli pokażesz im, że również masz wątpliwości, mogą poczuć się bardziej swobodnie z recenzjami.

#13
  0
njzk2
2020-03-07 01:32:20 UTC
view on stackexchange narkive permalink
  • Porozmawiaj o tym podczas regularnych spotkań zespołu (na przykład jeśli masz codzienne problemy lub coś podobnego):
    • „Kod, nad którym pracuję, jest kompletny, muszę go zdobyć recenzja. ”
  • W tej chwili znajdź kogoś, kto to zrobi:
    • „ Kto może się tym zająć / kto ma czas / komu mogę przydzielić to? ”
  • Uzyskaj ustne zobowiązanie, jeśli to możliwe, harmonogram (przed obiadem, do 3, później w ciągu dnia, jutro ...)
    • „Dzięki, połączę to później, aby dotrzymać tego a takiego terminu”
  • Pokaż to w dowolnym systemie, z którego korzystasz (np. W bitbucket, przypisz tę osobę jako recenzenta)
  • Przywołaj to ponownie podczas stand-up, jeśli twój kod nie został sprawdzony.
    • „Chłopaki, to mnie blokuje, w przeciwnym razie musi zostać przejrzane funkcja A nie może zostać wysłana w przyszłym tygodniu ”

Później porozmawiaj w stylu retro (jeśli to masz) lub na spotkaniu ad hoc, aby wyjaśnić że przegląd kodu jest częścią pracy każdego, że jest dobry sposób, aby dowiedzieć się, nad czym pracują inni, dowiedzieć się, jak działają, czy jest to konieczne dla zespołu i aby coś dostarczyć, itd. - zakładam, że wiesz, do czego służą recenzje kodu :)

#14
  0
ti7
2020-03-10 01:52:40 UTC
view on stackexchange narkive permalink

Obaj miałem i doświadczyłem tego problemu - głównie główną przyczyną jest jeden lub oba z nich

  • Tworzysz dużą ilość prawdopodobnie dobrego kodu (co oznacza, że ​​nie mają one rzeczywistego wkładu poza błahostkami)
  • Twój styl kodu lub język źródłowy jest bardzo nieznany (co oznacza, że ​​nie są pewni swojej recenzji, a co gorsza potrzeba przeczytania stosów dokumentacji, aby ją zrozumieć)

Nawet jeśli istnieje prawny powód, aby wymagać od recenzentów, a nie kaprysów wydziałowych, nie martw się bezpośrednio o ich recenzje , ale zapewnij narzędzia aby pomóc im przejrzeć Twój kod - to da im pewność co do brzmienia Twojego kodu jako całości, zamiast przeszukiwać każdą linię pod kątem brakujących błędów

  • napisz testy dla twojego kodu i poproś o recenzje testów. postaraj się napisać dobry opis wokół celu testów
  • poproś szefa (?) o pracę i pracuj z nim, aby utworzyć elementy pracy dla testy przeciwko konkretna funkcjonalność
  • jeśli to możliwe, zebrać pokrycie, aby udowodnić, że testy obejmują wszystkie branże, których się spodziewasz

To znacznie ułatwi współpracownikom sprawdzenie tego, co napisałam, ponieważ wkładając wkład w testy i widząc dobry wynik, będą mieli pewność, że działa!

Dodatkowo staraj się spotykać regularnie, aby wszyscy członkowie pokazywali coś, co ich zdaniem było fajne w ciągu ostatniego tygodnia (?). Idź ostatni i pamiętaj, aby nie grzebać przez cały czas - będzie ich więcej i powinny być słusznie interesujące, a nie czas na popisywanie się lub „nauczanie” swojej rzeczy. Pomoże to każdemu zapoznać się ze stylami i narzędziami innych osób, które mogą być używane do zrozumienia i rozwijania ich logiki.



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...