Są prośby wyciągnąć miejsce do szkolenia juniorów


11

Mamy koncepcję, że cały kod z żądania ściągnięcia do wzorca powinien być gotowy do produkcji. To ma sens i moim zdaniem jest to uczciwe stwierdzenie.

Chodzi o to, że po utworzeniu PR oświadczasz, że byłbyś w stanie to opanować, ale chciałbyś, aby niektórzy recenzenci po prostu „zgodzili się” z tobą i zauważyli wszystko, co przegapiłeś.

Ponieważ jesteśmy tylko ludźmi, popełniamy błędy i mamy nadzieję, że inni recenzenci mogą znaleźć przedmioty, których testy jednostkowe nie mogłyby znaleźć - błędy ortograficzne, nieprawidłowe javadoki itp.

ALE, czy Pull Request jest miejscem, w którym powinniśmy zapewniać programistom pewien poziom pomocy / szkolenia, a jeśli tak, to na jakim poziomie?

Za każdym razem, gdy wprowadzasz nowe zmiany, recenzenci muszą ponownie przejrzeć zmiany, co bierze od czasu ich opracowywania i powoduje ponowne sprawdzenie zmian.

Ile więc oczekiwanych treningów powinno być dozwolone w zapytaniach Pull? Część mnie uważa, że ​​różni się od juniorów do seniorów. Jednak uważam również, że nie powinno to być miejsce do znalezienia dużej ilości problemów - nawet dla juniorów.

Czy ktoś jeszcze stara się zmusić programistów do osiągnięcia celu „Moje żądanie ściągnięcia powinno być gotowe do produkcji”?

Odpowiedzi:


13

Nie. Prośby o pociągnięcie nie są miejscem szkolenia. Twój zespół ma właściwy pomysł. PR oznacza „Myślę, że dobrze jest iść. Czy mogę uzyskać 2. zestaw oczu na wypadek, gdyby coś mi umknęło. W końcu jestem człowiekiem”. Podejrzewam, że właśnie to robi twój uczeń. Oni szczerze myślą, że dobrze jest iść.

Oto ekstremalny pomysł (gra słów zamierzona). Sparuj program z uczniem, który powoduje zgagę. Jako starszy członek zespołu Twoim zadaniem jest ich podnieść i doprowadzić do produktywności.


Dzięki @RubberDuck. Program parowania to świetny pomysł i my to robimy - trochę. Podejrzewam, że powinniśmy to robić więcej. Jednak niektóre właściwe mierniki lub narzędzia do pomiaru, jeśli jeden z twoich „kropli” w oceanie wielokrotnie popełnia te same błędy, pomogłyby w ustaleniu, kto potrzebuje programowania tej pary. Jestem pewien, że problem ten nasila się w przypadku większych zespołów !?
Riaan Schutte

2
Cóż, argumentowałbym, że wszyscy musimy parować przez większość czasu. Jeden z naszych uczniów złapał więcej niż kilka moich błędów i jestem jednym z starszych członków zespołu. Prawdopodobnie możesz zapytać o liczbę komentarzy dotyczących żądań ściągnięcia, ale nie poleciłbym tego. Coś o osobach i interakcjach ... Poważnie. Twoim zadaniem jest podnieść tego dev. Zdobądź kopię Clean Code lub coś takiego.
RubberDuck

1
W miejscu pracy, w którym każdy programista pracuje nad ofertą dla klienta (bez wewnętrznych projektów, które się finansują), programowanie par nie jest tak łatwe, ale pozostaje ważne! Wygląda na coś, co firma może po prostu wypracować i zainwestować, jeśli chcemy bardziej produktywnych programistów na cytowaną pracę.
Riaan Schutte

1
Hmm ... dlaczego to nie jest takie proste? Czy klient nie otrzymuje tyle samo roboczogodzin, a co ważniejsze, lepszej wartości za dolara? Powodzenia, kolego. Uspokój się.
RubberDuck,

3
To powszechne nieporozumienie @Andy. To po prostu nieprawda. Tak, wiem, że to sprzeczne z intuicją.
RubberDuck

9

Jeśli kod, który narusza podstawowe zasady projektowania lub standardy zespołu, przejdzie do etapu żądania ściągania, zdecydowanie należy się nim zająć. A przeglądy kodu mogą być dobrym sposobem komunikowania standardów zespołu i praktyk projektowych.

Ale czy to najlepsze miejsce? Oto kilka powodów, dla których nie powiedziałbym:

  1. Jeśli potrzeba kilku iteracji przeglądu kodu, aby rozwiązać podstawową wadę projektu lub problem na dużą skalę, pojawi się silna pokusa, aby przeoczyć bardziej drobne problemy wymienione powyżej, z powodu terminów lub ogólnego wyczerpania przeglądem. Najlepiej byłoby, gdyby zespół był wystarczająco odporny, aby oprzeć się tej pokusie, ale prawdopodobnie najlepiej nie tworzyć sytuacji, która do tego doprowadziłaby.
  2. Otrzymanie recenzji kodu z dużą liczbą komentarzy nie jest świetnym doświadczeniem dla młodszego / nowego programisty. Tak, reagowanie na opinie to umiejętność, którą będą musieli rozwinąć, ale prawdą jest również to, że programiści nie zawsze mają umiejętności taktycznego reagowania na kod, którego nie lubią.

Pary programowania i przeglądy projektu są preferowane miejsca dla opinii na większą skalę.

To powiedziawszy, byłoby jeszcze gorzej pozwolić kodowi przejść z obawy, że zajęcie się nim podczas recenzji kodu jest „niewłaściwe”, i mogą wystąpić pewne okoliczności (np. Zdalne zespoły), w których jest to najlepsze, co możesz zrobić. W takim przypadku należy rozwiązać problemy z przeglądem kodu, a także rozwiązać problemy związane z procesem programistycznym, do którego doszło.

Chociaż znalezienie problemu podczas żądania ściągnięcia może nie być idealne, z pewnością jest lepsze niż w testowaniu lub w problemie produkcyjnym.


5

Powiedziałbym to bardziej, ponieważ żądania ściągania nie powinny być jedynym miejscem, w którym trenujesz ludzi. Ponadto młodsi programiści nie są jedynymi, którzy mogą potrzebować szkolenia w zakresie żądania ściągania. Kontrahenci, współpracownicy open source, deweloperzy z innych działów, którzy nie znają lokalnego kodeksu lub standardów, a nawet doświadczeni programiści potrzebują od czasu do czasu przypomnień, gdy popadną w samozadowolenie.

Przez pewien czas utrzymywanie otwartej prośby o pociągnięcie jest bardzo małe. Przekaż tyle lub mniej opinii, ile chcesz, przez tyle osób, ile chcesz, a następnie zostaw to w spokoju, dopóki autorzy nie powiadomią Cię ponownie, że uważają, że jest gotowy do połączenia. Żądanie ściągnięcia jest doskonałym centralnym narzędziem do komunikowania się o proponowanych zmianach kodu, niezależnie od tego, czy są one w pełni gotowe, czy wymagają dużo pracy.

Niektóre recenzje wniosków o ściągnięcie okazują się niewiele więcej niż pieczątka, a niektóre, które są zewnętrznymi przesłaniami do zespołu, mogą potrwać miesiąc w tę iz powrotem. Pierwszy rodzaj jest miły, kiedy można go zdobyć, ale to nie znaczy, że drugi rodzaj nie jest cenny. Próba nakłonienia ludzi do ciągłego przesyłania idealnych wniosków ściągania będzie frustrująca dla wszystkich.


Dziękuję za odpowiedź @ Karl-Bielefeldt. Zgodzono się, że można się spodziewać pewnego szkolenia, ale pytanie brzmi: ile jest odpowiednie, do jakiego poziomu. Twoje stwierdzenie „... czy są w pełni gotowe, czy wymagają dużo pracy”. Powiedziałbym, że PR do opanowania nigdy nie powinien wymagać dużo pracy. Dużo pracy wiąże się z wadami projektowymi, wadami implementacyjnymi zamiast pomagać mi dostrzec to, co przegapiłem. Zgadzam się jednak i doświadczyłem: „Ciągłe zachęcanie ludzi do składania idealnych wniosków ściągania będzie frustrujące dla wszystkich”.
Riaan Schutte

2

Zawsze czułem, że jedną z cech dobrego leadu jest ktoś, kto zapewnia dodatkowe szkolenie w razie potrzeby podczas każdego cyklu rozwoju. Dla mnie oznacza to, że nie tylko koduję siebie lub przeglądam kod, ale siedzę z większą liczbą młodszych programistów, łącząc programowanie z nimi, aby pomóc im uniknąć rodzaju min lądowych, na które nadepnąłem.

Głównie nie mam złudzeń, że naszym głównym celem jest edukacja - nie jest. Niezależnie od tego, czy jesteś seniorem, liderem czy młodszym programistą, celem nie jest twoja edukacja. Celem jest zawsze dostarczenie klientowi kodu jakości. Najlepiej na czas, z ograniczonym budżetem, robiąc to, co chcą. Zdaję sobie jednak sprawę z tego, że nie jestem w stanie wykonać całej pracy sam, więc spoczywa na mnie jako przewodniku, który pomoże wszystkim pomóc zespołowi odnieść sukces. A to oznacza rozpoznanie możliwości szkolenia, kiedy pojawiają się w naturze.

Tak więc na twoje pytanie, czy prośby o pociągnięcie są miejscem szkolenia juniorów, muszę powiedzieć, że nierzadko zdarza się, aby podczas nich pojawiały się uczące się chwile. Hej, będziesz musiał poradzić sobie z pierwszym konfliktem scalania, przejdźmy do tego po przeglądzie. Och, spójrz, nie uwzględniłeś żadnych testów jednostkowych dla swojego DAO, odłożymy twoją recenzję do czasu, gdy będziemy mieli okazję omówić te nowe metody. Dlaczego uważasz, że lepiej byłoby stosować podwójne prymitywy w tych obliczeniach finansowych niż BigDecimals? Tak, to nie jest naprawdę rzadkie.

Tak więc, chociaż powiedziałbym, że na pewno może się to zdarzyć, ale najwyraźniej nie jest to główny cel żądania ściągnięcia. Nie uważam też, że można oczekiwać, że kod w żądaniu ściągnięcia jest gotowy do produkcji. Często tak nie jest.

Jeśli używasz gałęzi funkcji i wydania w strategii rozgałęziania w stylu gitflow, twoje żądania ściągnięcia stają się czymś w rodzaju kandydatów do wydania. Nie jest gotowa do produkcji, ale coś bardziej zbliżonego. Wiesz, że twój kod się kompiluje (po prawej) i masz wystarczającą liczbę testową covfefe, aby przyznać, że spełnia on cele historii użytkownika. A ponieważ przeprowadziłeś już kilka testów integracyjnych w swoim środowisku programistycznym, masz świetną wersję demonstracyjną gotową do użycia, jeśli zostaniesz poproszony o zademonstrowanie swoich zmian, co zrobisz podczas przeglądu twojego PR.

Ostatecznie uważam, że powinniśmy udzielać pomocy podczas przeglądów PR, ale nie dotyczy to ogólnego kodowania. Zamiast tego wiąże się z przygotowaniem proponowanego kodu do włączenia z roboczą bazą kodu jakości produkcyjnej. PR jest dla programistów okazją do wykazania, że ​​mają uzasadnienie i solidne zrozumienie każdej zmiany, którą wprowadzili w PR. I nawet wtedy - nawet po obciążeniu ich testami jednostkowymi, demonstracjami i mnóstwem pytań - wciąż nie oczekujemy, że proponowane zmiany są gotowe do produkcji.

Kod jest już zamknięty. Ale potem pozwalamy QA torturować to.


Dzięki za odpowiedź @ Michael-Peacock. To, co mówisz, odnosi się do firm, które mają osobny dział kontroli jakości lub testerów, którzy przechodzą przez kolejny etap. Ale gdy programiści są również testerami, PR towarzyszy wszystkim, od programowania, przez testowanie, aż po scalenie w master. W tym przepływie pracy kod musi być gotowy do produkcji po zatwierdzeniu PR. Przypuszczam, że pytanie zawiera również założenie dotyczące używanego przepływu pracy.
Riaan Schutte

Argumentowałbym, że nawet jeśli nie masz dedykowanego zespołu ds. Kontroli jakości, jeszcze ważniejsze jest upewnienie się, że dodałeś testy integracyjne i / lub akceptacyjne do swojego przepływu pracy, i zapewniłeś czas na potencjalną przeróbkę, jeśli scalony kod nie przejdzie testów. Możesz zautomatyzować niektóre testy akceptacyjne za pomocą Selenium i Cucumber, aby zmniejszyć obciążenie deweloperów, ale myślę, że ważne jest, aby nie zakładać, że kod jest gotowy do produkcji, dopóki nie zademonstrujesz tego poprzez testy.
Michael Peacock

Całkowicie się zgadzam, dlatego wszyscy kodujemy, ponieważ wymagamy powiązanych testów. Jeśli następnie zmienisz bazę danych przed połączeniem, możesz być pewien, że testy przejdą pomyślnie i kod powinien działać zgodnie z oczekiwaniami.
Riaan Schutte

2

Chcę podziękować wszystkim za ich wkład i pomóc mi zrozumieć, co ludzie mają do powiedzenia na ten temat.

To jest moja odpowiedź po otrzymaniu opinii i moje zrozumienie w oparciu o otrzymane odpowiedzi i komentarze. Dziękuję wszystkim.

Podsumowanie

  • Nie należy oczekiwać ani egzekwować doskonałych żądań nietoperza, ponieważ będzie to frustrujące tylko dla wszystkich zaangażowanych.
  • Nadal jednak dążymy do tego, aby naszym celem były idealne żądania ściągania.
  • Oczekuj pewnej współpracy / pomocy w żądaniach ściągania. W końcu tego właśnie żądasz, tworząc żądanie ściągnięcia.
  • Jeśli robi się to trochę z powodu wad projektowych lub wad implementacyjnych, spędzaj czas z tym deweloperem i wykonaj programowanie parowe, aby je zbudować i zbliżyć kod do celu . To jest rola wszystkich starszych programistów.
  • Juniorzy będą potrzebowali więcej sesji programowania par niż programiści pośredni. Spodziewaj się, że żądania ściągnięcia odzwierciedlą to wymaganie.
  • Zachęcaj programistów do spotkań projektowych / wdrożeniowych przed dotknięciem kodu, aby zredukować wszelkie poprawki zidentyfikowane w Żądaniach ściągania.

1
Wspaniałe podsumowanie i odpowiedź. Nie obraziłbym się wcale, gdybyś dał sobie znak wyboru.
RubberDuck,

Dzięki @RubberDuck, ale moje podsumowanie nie mogłoby istnieć bez odpowiedzi i komentarzy wszystkich na moje pytanie. Twoje zdrowie.
Riaan Schutte

0

Czy możesz powiedzieć coś więcej o kulturze swojej firmy w kategoriach zespołów technicznych? Jeśli masz problem z gotowością kodu do produkcji, gdy programista chce połączyć się z linią główną, to co tak naprawdę mówisz swoim programistom? Mówisz im, że kiedy ich praca jest „skończona”, to w porządku, jeśli nie działa? Wszystko w porządku, jeśli zepsuje system? Jeśli dodają dług techniczny, może to w porządku, jeśli mogą to uzasadnić i są świadomi tego, co robią, i pokazać, że mogą wrócić i dokonać refaktoryzacji później. Ale jeśli są nieświadomi, dlaczego robią coś niebezpiecznego, ile razy pozwolisz temu przejść?

Jeśli masz młodszego programistę, ich pierwsze żądania ściągania będą oczywiście mieć problemy. W końcu powinni się z tym pogodzić. Jeśli zauważysz, że nadal występują problemy, być może przypisujesz im pracę, na którą nie są jeszcze przygotowani?

A może musisz zatrudnić zastępczego juniora i zwolnić tego, który nie był w stanie tego rozgryźć?

Wiesz co widziałem? Ludzie, którzy nie są kompetentnymi programistami, pracują w firmie od lat tylko z powodu nepotyzmu. Oczywiście ich żądania ściągania wymagają wielu recenzji. W języku Lean są one „marnotrawstwem” - zaciągnięcie się do zespołu i przeciągnięcie do dolnej linii.

Musisz więc sam zdecydować: ile żądań pociągnięcia zajmie, aby twoi juniorzy wykazali się kompetencjami i czy masz odwagę puścić tych, którzy tego nie robią?


Dziękujemy za odpowiedź na @RibaldEddie. Oczekujemy, że programiści napisaliby testy jednostkowe, ręcznie przetestowali i sprawdzili swoją pracę do tego stopnia, że ​​stwierdziliby, że ten kod jest świetny i gdyby pozostawiono go, scaliliby go w master, ale poprosi 2 recenzentów o sprawdzenie go i mam nadzieję, że potwierdzi to oświadczenie. Nie przyjmujemy żadnych długów technicznych i całkowicie odchodzimy od poprawek na rzecz rozwiązań. Oczekuje się, że kod spełni te wymagania.
Riaan Schutte

@Riaan, którzy są recenzentami?
RibaldEddie

Każdy od technicznych prowadzi do juniorów. Zwykle jest to jeden starszy / średni recenzent wraz z młodszym / średnim recenzentem. (2 recenzentów)
Riaan Schutte

@Riaan z czasem spodziewałem się, że młodsi członkowie zespołu będą się wyróżniać. Będziesz mógł powiedzieć, kto jest sumienny, a kto nienazjalny. Uważam, że tworzenie oprogramowania wykonane dobrze jest działaniem dobrze dopasowanym do mentalności zorientowanej na szczegóły. Niektóre osoby mogą nie być w stanie tego zrobić. Musisz zdecydować, co z nimi zrobić. Zasadniczo należy jednak oczekiwać, że programiści przesyłający kod do scalenia będą pewni, że działa on zgodnie z przeznaczeniem i jest gotowy do produkcji. Nawet jeśli masz duży, wyrafinowany zespół kontroli jakości, twoi deweloperzy powinni nadal przygotowywać kod PR gotowy do produkcji.
RibaldEddie
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.