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”?
źródło
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:
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.
źródło
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.
źródło
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.
źródło
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
źródło
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ą?
źródło