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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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?”

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.

• 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 :)

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.