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.
Odpowiedzi:
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:
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ą.
źródło
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.
Aby się dowiedzieć, musisz najpierw zrozumieć cel recenzji kodu. Wspomniałeś o zaufaniu - to dobre „przybliżenie”, ale nie do końca dokładne.
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).
źródło
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.
źródło
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.
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.
źródło
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.
źródło
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ć)
źródło
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.
źródło
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ąć.
źródło
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.
źródło