Co powinienem zrobić, czekając na recenzję?

32

Zanim zadam pytanie, muszę wyjaśnić sytuację.

Pracuję dla firmy jako młodszy inżynier oprogramowania. Jeden z seniorów zawsze mnie powstrzymuje, gdy skończę swój rozwój i chce się zaangażować.

Zawsze chce, żebym czekał, aż to przejrzy. Jest to w porządku, ponieważ zwykle znajduje pewne błędy i dokonuje pewnych optymalizacji.

Jednak muszę zatwierdzić swój kod przed upływem terminu. Kiedy skończę, dzwonię do niego i mówię, że jest skończony. Zwykle spóźnia się. Więc mój kod też się spóźnia.

Moje pytanie brzmi: co powinienem zrobić? Czy powinienem czekać na recenzję?

EDYCJA: Uzupełnienie pytania. Jestem ciekawy jeszcze jednego problemu.

Chcę być wolny podczas kodowania. Jak zdobyć zaufanie do wolności rozwoju?

Kilka wyjaśnień: rozmawiałem z nim o tym. Ale to nie pomogło. Używamy już narzędzia do śledzenia problemów, ale nie ma żadnych zadań do recenzji. Są tylko zadania programistyczne i testowe.

yfklon
źródło
10
Porozmawiaj z nim o tym.
Florian Margaine
18
wyślij do niego e-maila z informacją, że zostało zrobione, a ty czekasz na jego recenzję. Wtedy zawsze możesz odesłać do tego e-maila, jeśli ktoś zapyta, dlaczego nie dotrzymałeś terminu.
dreza
5
Narzędzie do śledzenia problemów to tylko narzędzie przypominające o ważnych krokach, których zespół nie chce zapomnieć. Jeśli Twój zespół postrzega recenzje jako jeden z tych kroków, recenzje prawdopodobnie powinny zostać dodane jako osobne zadania. Jeśli Twój zespół jest w stanie poradzić sobie z tym, które części kodu muszą zostać przejrzane bez wyraźnego wpisania tego do narzędzia do śledzenia problemów, nie ma potrzeby dodawania takich zadań. To jest coś, o czym powinieneś porozmawiać ze swoim zespołem.
Doc Brown
3
Bądź cierpliwy, nie masz pojęcia, jak korzystne jest, aby druga para oczu (szczególnie starszy) przeglądała Twój kod.
JeffO

Odpowiedzi:

70

Więc mój kod też się spóźnia.

Nie, to nie jest twój kod, to kod ciebie i seniora. Pracujesz jako zespół, ponosisz wspólną odpowiedzialność, a gdy dotrzymujecie terminu, to jest to wina was obojga. Upewnij się więc, że ten, który dotrzymuje terminów, zauważa to. Jeśli ta osoba również uważa to za problem, na pewno porozmawia z wami obojgiem - może to pomóc nie tylko w rozmowie z tobą, współpracownikiem.

I do EDYCJI:

Chcę być wolny podczas kodowania. Jak mogę zdobyć zaufanie do wolności rozwoju?

Przeglądanie kodu jest jednym z najważniejszych oszczędzaczy jakości. Praktycznie niemożliwe jest napisanie doskonałego kodu bez drugiej pary oczu, nawet jeśli masz> 20 lat doświadczenia w programowaniu. Dlatego w dobrym zespole kod każdego powinien być stale sprawdzany - zarówno kod twojego seniora, jak i kod. Nie ma to nic wspólnego z nieufnością wobec ciebie osobiście (a przynajmniej nie powinno). Tak długo, jak uważasz, że „darmowe kodowanie” bez drugiej pary oczu jest lepsze, nadal jesteś młodszym programistą.

Doktor Brown
źródło
4
@blank: przegapiłeś mój punkt - mówię o obowiązkach i twoim punkcie widzenia na ich temat. Uważasz, że tylko ty jesteś odpowiedzialny za dotrzymanie terminu - to źle, i powinieneś upewnić się, że wszyscy inni w zespole też to wiedzą.
Doc Brown
Masz rację. Ale senior nie ponosi odpowiedzialności. Nie ma dla niego zadania sprawdzania kodu. Ale robi to zawsze.
yfklon 30.04.13
27
@blank: właśnie o to mi chodzi - jeśli senior każe ci czekać, bierze odpowiedzialność. Uczyń to przejrzystym dla tego, kto określa terminy.
Doc Brown
27

W dobrym zespole powinieneś mieć przydzieloną kolejkę zadań programistycznych w narzędziu do śledzenia problemów .

W ten sposób, czekając na recenzenta, możesz ( powinien ) pracować nad kolejnym zadaniem czekającym w tej kolejce. Gdy już przyzwyczaisz się do pracy w ten sposób, otworzy się możliwość przeglądu zmian w „partiach”, zmniejszając w ten sposób opóźnienia.

  • Jeśli nie masz takiej „kolejki”, przedyskutuj to ze swoim przełożonym lub jeszcze lepiej z recenzentem. Jeśli Twój zespół nie ma dość wygodnego narzędzia do śledzenia problemów dla takich rzeczy, zastanów się nad studiowaniem tablic z ofertami pracy lub wewnętrznymi ofertami pracy w firmie, aby znaleźć lepszy zespół (możesz również omówić to z kierownikiem / recenzentem, ale nie oczekuj, że to pomoże - brak dobrego trackera problemów jest często objawem poważnego uszkodzenia zespołu).

Chcę być wolny podczas kodowania. Jak mogę zdobyć zaufanie do wolności rozwoju?

Aby się dowiedzieć, musisz najpierw zrozumieć cel recenzji kodu. Wspomniałeś o zaufaniu - to dobre „przybliżenie”, ale nie do końca dokładne.

  • Na przykład, w jednym z moich ostatnich projektów rozwój został opracowany przez mini zespół mnie i mojego kolegi. W pełni wzajemnie sobie zaufaliśmy i szanowaliśmy się - ale mimo to sprawdziliśmy 100% kodu. Robiliśmy to, ponieważ pozwoliło nam to znaleźć i szybko naprawić niektóre błędy, a także, co jest bardzo ważne, ponieważ recenzje nie zajęły dużo czasu i nie zablokowały naszej pracy.

Widzisz, dokładniej byłoby pomyśleć o recenzjach kodu pod względem nakładów włożonych w celu uniknięcia pewnego ryzyka . W dobrym zespole możesz spodziewać się pewnego rodzaju wspólnego zrozumienia tego, jak „odpowiednio zrównoważyć” to. Zauważ, że nie ma jednej idealnej równowagi, wszystko zależy w dużej mierze od projektu - ryzyko i wpływ błędów w oprogramowaniu o kluczowym znaczeniu naturalnie różni się od tego w aplikacji niekrytycznej.

Korzystając z tego przykładu, możesz spodziewać się „blokowania recenzji”, o ile wysiłki zainwestowane przez recenzenta są uzasadnione przez znalezienie błędów i ulepszeń, które lepiej naprawić przed zatwierdzeniem kodu.

Prawdopodobnie oczekują, że dzięki praktyce i wskazówkom otrzymanym w recenzjach poprawisz kodowanie, aby znaleźć coraz mniej problemów, które warto naprawić przed zatwierdzeniem. Gdy tylko odkryją, że Twój kod jest „wystarczająco bezpieczny”, aby umożliwić mniej kłopotliwe „środki zapobiegania ryzyku”, możesz spodziewać się zmiany tego procesu, na przykład recenzji po zatwierdzeniu .

W zależności od projektu, w pewnym momencie twój kod może być nawet uznany za wystarczająco bezpieczny, aby w ogóle pomijać recenzje, pozostawiając wykrycie błędów testerom (ale niekoniecznie tak się stanie, patrz mój przykład powyżej).

komar
źródło
1
Wygląda na to, że sugerujesz techniczne rozwiązanie problemu organizacyjnego. Z mojego doświadczenia wynika, że ​​rzadko to działa.
Doc Brown
5
@DocBrown Nie sądzę, że te odpowiedzi naprawdę koncentrują się na rozwiązaniu technicznym. Istotą rozwiązania jest „powinieneś mieć przydzieloną kolejkę zadań”. To rozwiązanie organizacyjne problemu organizacyjnego. Niezależnie od tego, czy kolejka jest utrzymywana w narzędziu do śledzenia problemów, wiadomościach e-mail, arkuszu kalkulacyjnym, tablicy lub stosie wpisów, które zauważa, to tylko szczegół.
Carson63000 30.04.13
@ Carson63000 dokładnie tak. Dodałbym również, że posiadanie zadań w narzędziu do śledzenia problemów, aby nie trzeba było biegać do menedżera / seniora, aby poprosić o nowe zadanie, jest również szczegółem organizacyjnym (i nie dość drobnym z mojego doświadczenia)
gnat
1
@gnat: cóż, mógłbyś napisać „na przykład w narzędziu do śledzenia problemów”, aby to wyjaśnić. Ale nie jestem pewien, czy pytanie, na które odpowiadasz (to z tytułu), jest głównym punktem pytania PO napisanego w tekście poniżej (który jest inny).
Doc Brown
@DocBrown Nie zrobiłem tego celowo, ponieważ uważam, że jest to zbyt ważny szczegół organizacyjny, aby stwierdzić, że jest „na przykład” (sama myśl o młodszych kolegach z drużyny przychodzi do mnie z prośbą o następne zadanie, gdy są skończone z prądem, wywołuje dreszcz w moim kręgosłupie )
komar
9

Istnieje wiele możliwych odpowiedzi w zależności od tego, jaki jest twój problem.

  • Jeśli Twoim głównym problemem jest „nie dotrzymuję terminów”, nie. Dwaj z was wspólnie nie dotrzymują terminów. Czy możesz (z pewnością) powiedzieć: „Skończę za godzinę, czy możemy wtedy dokonać przeglądu kodu”? To może wystarczyć. Czy możesz wypełnić kod dzień przed upływem terminu? To powinien być obfity bufor. Czy uzupełniasz kod, mając dużo bufora między „sprawdzeniem” a terminem? Jeśli to drugie, to nawet nie wspólna wina, powiedziałbym.

  • Kod powinien być zawsze sprawdzany. Nie mogę niczego zameldować bez (przynajmniej) drugiego zestawu oczu i innego człowieka, który mówi „to w porządku”. Dotyczy to projektów, w których jestem głównym programistą, a także projektów, w których normalnie nie uczestniczę (ale udało mi się znaleźć błąd wpływający na mnie, który chcę naprawić). Jednak surowość recenzji opiera się w dużej mierze na zaufaniu. Jeśli ufam, że osoba chcąca przesłać kod dobrze zna bazę kodu, nie będę tak rygorystyczny, jak gdybym nie wiedział, jak dobrze osoba zna bazę kodu.

Vatine
źródło
5

Moje pytanie brzmi: co powinienem zrobić? Czy powinienem czekać na recenzję?

Nie, nie powinieneś siedzieć bezczynnie. Zawsze jest coś do zrobienia. Jak sugerował Gnat , powinna istnieć kolejka zadań. Lub, w zwinny sposób rozwoju, lista zadań przypisanych do bieżącej iteracji. Jeśli siedzisz bezczynnie, coś jest nie tak w organizacji Twojej firmy lub zespołu.

Inna sprawa to: czy twój starszy przełożony naprawdę sprawdza każdy fragment kodu, który robisz? Jeśli tak, możesz także wykonać programowanie w parach.


Chcę być wolny podczas kodowania. Jak mogę zdobyć zaufanie do wolności rozwoju?

Istnieje kilka przepisów, które wymagają, aby senior sprawdził pracę młodszego dziecka (myślę, że iso medyczne tego wymaga 62304). Jeśli tak jest, nie możesz nic zrobić.

To, co możesz zmienić, to poprosić seniora, aby nie sprawdzał dosłownie wszystkiego. Możesz ustawić proces sprawdzania kodu i sprawdzać ważne rzeczy.

BЈовић
źródło
3

Użyj git lokalnie, zatwierdź zmiany w oddziale i zacznij od zadania 2, czekając. Następnie, gdy skończy, możesz scalić jego zmiany w swojej nowej pracy i już jesteś na dobrej drodze do następnego zadania.

Zrób to wystarczająco długo i już niedługo, będzie mógł przejrzeć 2 lub więcej rzeczy za jednym razem. Wybierz rzeczy, w których linie raczej się nie nakładają, aby zminimalizować konflikty.

Boatcoder
źródło
2

Jednym z rozwiązań tego problemu może być zaangażowanie wcześniejszego programisty w programowanie parowe w swoją pracę.

Strona Wikipedii na temat programowania par

Najbardziej oczywistą korzyścią dla ciebie jest to, że recenzja odbywa się znacznie wcześniej, więc nie musisz już czekać na starszego programistę.

Oprócz tego będziesz mógł zobaczyć procesy myślowe i techniki starszego programisty, gdy pisze kod, i wyciągać z tego wnioski.

Być może masz problem z tym, że starszy programista może nie chcieć się z tobą sparować. To może być trudne, ale z własnego doświadczenia wynika, że ​​zarówno starsi, jak i młodsi programiści zdobywają duże doświadczenie w programowaniu parami.

Często pojawia się również obawa, że ​​zmniejszysz o połowę wydajność, mając 2 programistów pracujących nad tym samym dziełem. Trudno jest zmierzyć, jaki wpływ na produktywność ma programowanie w parach, najczęstszą odpowiedzią, jaką słyszałem, jest to, że produktywność zespołów, które się łączą, i tych, które tego nie robią, jest mniej więcej taka sama. (Jeśli ktoś zna jakieś dobre badania na ten temat, chciałbym o tym usłyszeć)

Andy Lowry
źródło
2

Nie jest to pełna odpowiedź sama w sobie, tylko dodatek do doskonałych odpowiedzi powyżej ...

Czy przeglądasz swój kod przed jego wprowadzeniem? Wiem, że to nie jest najfajniejsze, ale staram się robić to przez większość czasu. Programuję zawodowo od 20 lat (łącznie 34 lata), ale zwykle znajduję co najmniej jeden błąd i / lub jedną rzecz, o której zapomniałem lub która mogłabym przynajmniej poprawić. Zgadzam się z opinią, że Twój kod powinien być zawsze sprawdzany i że drugi zestaw oczu jest lepszy niż jedna para. Ale nawet ta sama para dwa razy przeglądająca kod jest lepsza niż jeden raz.

Czy piszesz testy jednostkowe dla swojego kodu? Oprócz testów jednostkowych mam również mały skrypt powłoki, który wyszukuje najczęstsze błędy, które osobiście popełniam. Niektóre z nich to gramatyka angielska i pisownia, inne to problemy z kodowaniem, których kompilator nie wychwytuje. Uruchamiam go przed sprawdzeniem dużych zmian, dzięki uprzejmości dla wszystkich dalszych.

Zwykle pozwalam ludziom pisać kod i czasami narzekam na to później, ale nie sprawdzam każdego zameldowania. Kiedyś pracowałem z bardzo młodym programistą, którego kod musiałem przejrzeć i zwykle cofnąć, ponieważ popełnili tyle błędów. To nie skończyło się dobrze. Jesteś w zawodzie, w którym często ważniejsze jest, aby zrobić to dobrze niż zrobić na czas. Jeśli wyciągniesz wnioski ze swoich błędów, posuniesz się daleko.

Jeśli możesz zminimalizować liczbę zmian, które recenzent musi wprowadzić w kodzie, zmaksymalizujesz szansę, że zaufają Ci w pisaniu kodu, który nie zawsze musi być tak dokładnie sprawdzany. Jeśli chcesz uwolnić się od recenzji, weź maksymalną odpowiedzialność za jakość własnej produkcji.

Niektóre lub wszystkie z tych sugestii można wykonać, czekając, aż ktoś sprawdzi Twój kod.

GlenPeterson
źródło
1

Wydaje mi się, że ręczne przeglądy kodu to ... no cóż ... lata 80-te. Może 90-tych.

W dzisiejszej erze ciągłej integracji i systemów przeglądania kodu online, naprawdę nie chcesz wstrzymywać żadnych zatwierdzeń kodu tylko dlatego, że boisz się, że „może to przerwać kontrolę źródła”.

Dajcie spokój ludzie. Do tego służy zestaw zmian (lub listy zmian). Sprawiasz, że programiści karmią głodne paszcze twojego systemu kontroli źródła. Następnie serwer ciągłej integracji uruchamia się z litanią ukierunkowanych kompilacji (mam nadzieję, że to tylko codzienna kompilacja, ale niektórzy z nas dają się ponieść emocjom). Jeśli coś się zepsuje, odkładasz trofeum małpy kodowej (zwykle plastikową zabawkę, którą ktoś znalazł z pudełka z płatkami Lucky Charms) na biurku sprawcy i wycofujesz listę zmian. Cóż, niektóre systemy ciągłej integracji automatycznie wysyłają powiadomienia e-mail / IM / pulpitu do wszystkich w zespole / dziale / organizacji, że kompilacja jest zepsuta, wraz ze sprytnym hiperłączem, aby pokazać wszystkim, którzy dokładnie złamali kompilację, w którym pliku lub teście. To teraz nieszczęsny programista ”

W trakcie tego procesu uruchamia się system sprawdzania kodu (ponownie uruchamiany podczas odprawy). Lista wykwalifikowanych członków zespołu jest powiadamiana o tym, że lista zmian jest poddana kontroli źródła, przegląd jest uruchamiany w systemie recenzji i wszyscy zaczynają dodawać adnotacje do zmian na liście zmian. Mam nadzieję, że wszyscy powiedzą „LGTM”. Jeśli programista jest inteligentny, pamięta, aby się modlić / przekupić / ukryć. W przypadku poważnych problemów recenzenci mogą utworzyć defekt (który można podłączyć do systemu śledzenia błędów), a nawet zażądać wycofania listy zmian. Tak, wycofane zmiany zaszkodziły nie tylko ego, ale i umysłowi, to prawda. Jest to dobra przyprawa dla młodszych programistów, aby ponownie zintegrować listy odrzuconych zmian.

Jeśli w twoim środowisku deweloperskim brakuje CI lub systemu przeglądu kodu, powinieneś poważnie to sprawdzić. Kilka linków może ci pomóc:

Atlassian Crucible
JetBrains TeamCity
reitveld
Cruise Control

Jeśli zamierzasz uzyskać serwer CI, powinieneś poważnie pomyśleć o ramach testów jednostkowych. Jeśli jesteś programistą C #, poszukaj czegoś takiego jak NUnit, aby rozpocząć.

code4life
źródło
Nie wiem, kto głosował za tą odpowiedzią, ale nie zgadzam się z nim. Całkowicie zgadzam się z code4life, że przeglądu kodu należy dokonywać z kontroli źródła, a nie z kopii lokalnej. Zmiana, której wprowadzenie zajmuje trochę dnia, powinna być wprowadzana codziennie, może w oddziale, ale nadal należy ją zatwierdzać codziennie. Odtąd można dokonać przeglądu kodu przy częściowej zmianie, a CI, codzienne testy kompilacji i integracji można zastosować w tej gałęzi, gdy stanie się ona wystarczająco stabilna.
jfg956
Tak. W dzisiejszych czasach przeglądy kodu są wykonywane na liście zmian. Odrzucone listy zmian zostają wycofane (taka jest opcja nuklearna), lub defekty zostają podniesione. Chcemy jak najszybciej rzucić zatwierdzenia przeciwko CI, zgodnie z Kodem ukończonym McConnella.
code4life
Wydaje mi się, że ktokolwiek głosował za odpowiedzią, nie przeczytał pierwszej linii. Myślę, że pierwsza linia jest trochę myląca.
Vitalik,
LOL, cóż, 2010 ... to era ADHD-ism ...!
code4life
Po pierwsze: dlaczego wprowadzasz nowe słowo „ ręczna weryfikacja kodu”? Jak wyglądałaby automatyczna weryfikacja kodu? W moim rozumieniu przegląd kodu jest ręczny. Osoba czyta kod, aby potwierdzić, że dokładnie robi to, co powinna (nic mniej i nic więcej). Jakakolwiek automatyzacja, taka jak czyszczenie lub automatyczne testowanie, nie jest przeglądem kodu. (ciąg dalszy nastąpi ....)
spróbuj złapać w końcu
-1

Z wyprzedzeniem informujesz go, kiedy Twój kod będzie gotowy, a nie w momencie, gdy zostanie ukończony. Powinieneś być w stanie ustalić, że ok. tydzień wcześniej. To daje mu czas na przygotowanie i zaplanowanie recenzji, tak aby pasowała do obu twoich planów.

Jan Doggen
źródło