Jako młodszy inżynier oprogramowania zawsze analizowałem otrzymane komentarze dotyczące recenzji kodu, aby dowiedzieć się, jak zostać lepszym programistą. Ale kiedy przyszedł czas na moją pierwszą recenzję kodu, zdałem sobie sprawę, że moje doświadczenie nie przygotowało mnie do bycia po drugiej stronie.
Rozwinąłem poważny przypadek zespołu oszustów, który krąży w dół z pytaniami: czy powinienem skomentować ten wiersz kodu, czy nie warto? Czy powinienem znaleźć artykuły na poparcie każdego komentarza? Czy zawieszę witrynę, zatwierdzając to? Czy będą mnie nienawidzić? Dobra, przyznaję, że dość szybko ruszam w spiralę. Ale po rozmowie z niektórymi współpracownikami wiedziałam, że nie jestem sama w moich zmartwieniach.
Młodszych inżynierów oprogramowania można poddać przeglądowi kodu z założeniem analogicznym do „wiesz, jak czytać książkę, więc wiesz, jak napisać książkę, co nie jest prawdą”, mówi Jessica Rudder, inżynier ds. Doświadczeń w GitHub.
Są oczekiwania związane z recenzowaniem kodu, a proces może być nerwowy. Przeprowadziłem więc wywiad z siedmioma innymi inżynierami oprogramowania w celu zebrania wskazówek, jak zbudować sposób myślenia o recenzowaniu.
1. Pomyśl o ogólnym wpływie
Zasadniczo, dobre żądanie ściągnięcia (PR) powinno wpływać tylko na ograniczoną część bazy kodu. Ograniczony zakres nie powinien jednak uniemożliwiać myślenia o zmianie kodu w kontekście większej bazy kodu.
Nigel Munoz, były inżynier The Muse z pełnym stosem i obecny niezależny inżynier oprogramowania, zachęca recenzenta, by pomyślał o tym, „jak ta zmiana wpływa na coraz większy i mniejszy obraz”. Biorąc pod uwagę większy obraz, należy znaleźć wszelkie zadłużenie techniczne - poszukaj kodu który jest powtarzany, niemodularny lub nie jest zgodny z najnowszymi standardowymi konwencjami - a także analizuje zmiany w architekturze bazy kodu.
Sam Donow, główny programista w Hudson River Trading, uważa, że „nie ma nic zbyt dużego lub zbyt małego do skomentowania. Sugestie dotyczące drobnych ulepszeń mogą prowadzić do większych ulepszeń w wielu częściach bazy kodu. ”
Możesz użyć komentarza PR na GitHub, aby przekazać pozytywne opinie, a także wskazać, gdzie kod może różnić się od standardowych konwencji frameworka React.
Na przykład podczas jednej z moich recenzji kodu otrzymałem komentarz, że niektóre właściwości komponentu React były mylące, co wywołało szersze pytania o sposób użycia tego komponentu. Ostatecznie usunąłem właściwości z oryginalnego komponentu i utworzyłem osobny komponent, aby wyjaśnić zachowanie każdego z nich i zapewnić, że oba będą mogły być używane w większej liczbie miejsc.
2. Zastanów się nad bezpieczeństwem
Nie zapominaj, że niektóre zmiany mogą mieć wpływ nie tylko na bazę kodów. Rudder zaleca ocenę, czy użytkownik „mógłby użyć tej funkcji do nękania kogoś lub nadużyć systemu”. Na przykład, jeśli nowa funkcja w żądaniu ściągnięcia obejmuje wpis użytkownika, poszukaj iniekcji SQL, dostępu do danych, skryptów między witrynami i inne luki w zabezpieczeniach.
3. Skoncentruj się na błędach
Twoimi współtwórcami kodu - bez względu na to, jak robotowi mogą się wydawać - są ludzie, a ludzie mogą łamać lub zapominać o funkcjach. Dlatego upewnij się, że „sprawdzasz testy z taką samą wagą jak reszta kodu”, radzi Abhishek Pillai, lider technologiczny w Teachers Pay Teachers. „Zapobiegną nowym błędom i będą służyć jako dokumentacja dla każdego, kto będzie nad tym pracował w przyszłości.”
Czytanie testów może pomóc ci zrozumieć funkcjonalność nowej funkcji i zobaczyć różne przypadki, które wprowadzi, podczas gdy analiza testów może pomóc ci wskazać brakujące przypadki i znaleźć funkcje nie zawarte w niniejszym PR. Jeśli zmiana kodu nie obejmuje testów i wydają się one odpowiednie, należy poprosić o nie w ramach przeglądu.
Ale testy to nie wszystko. „Nie pokładaj zbyt dużej wiary w system”, ostrzega Donow. „Tylko dlatego, że przeprowadzone testy nie oznaczają, że nie ma żadnych błędów”.
Możesz także „uruchomić aplikację lokalnie, aby funkcjonalnie ją przetestować i upewnić się, że działa. Jeśli to nie działa, nie ma sensu dalej sprawdzać ”- mówi Ryan Verner, programista w 8th Light. Chociaż niektórzy recenzenci nie sądzą, że ręczne testowanie powinno być częścią procesu przeglądu kodu - częściowo ze względu na czas, jaki zajmuje - Verner uważa, że jest to szybki sposób na określenie, czy należy poświęcić więcej czasu na przeglądanie, a także strategię, która pomoże ograniczyć wzrost zaległości błędów.
4. Bądź graczem zespołowym
Klisza nabiera nowego znaczenia, jeśli chodzi o recenzowanie kodu. „Poświęć trochę czasu na sprawdzenie, ponieważ jest to podstawa kodu dla wszystkich” - mówi Verner, który opowiada się za poczuciem „zbiorowej własności”. Ty, jako recenzent, powinieneś pracować nad ochroną zaległości związanych z błędami przed powiększaniem się, aby dać mniej pracy zespołowej.
Pillai używa gifów, aby uczcić zatwierdzone i gotowe do połączenia PR członków swojej drużyny.
Jednocześnie Charles Luxton, lider technologiczny w Muse, zachęca recenzenta do zrozumienia i zapamiętania priorytetów zespołu. W obliczu szybko zbliżających się terminów i nieporozumień, czasami tworzenie rzeczy do zrobienia dla zaległości, która zapewnia, że w przyszłości zostaną wprowadzone ulepszenia, a tymczasem komentarz do kodu, o którym mowa, jest pomocą, której potrzebujesz, aby dbaj o zadowolenie swojego zespołu.
Na koniec, zadając sobie pytanie, czy kod miałby sens dla kogoś, kto właśnie dołączył do zespołu i czytał go w ciągu pierwszych kilku tygodni, pomoże utrzymać twój kod w stanie czytelnym i zrozumiałym.
5. Użyj procesu uczenia się i dzielenia się wiedzą
Proces recenzji daje wszystkim zainteresowanym miejsce, aby uzyskać lepszy wgląd w bazę kodu, języki, frameworki i najlepsze praktyki.
Matt Jeffery, kierownik ds. Technicznych w Muse, radzi recenzentowi, by „zrozumiał zmiany architektonicznie. Jednym ze sposobów jest odczytanie nazw plików, ponieważ pomagają one nadać kontekst. Na przykład, jeśli patrzysz na zmianę w warstwie dostępu do danych wiesz, że nie masz do czynienia z logiką biznesową ani interfejsem użytkownika ”.
Możesz użyć komentarza PR na GitHub, aby udostępnić dokumentację.
Kiedy uczysz się na podstawie zmian w kodzie, masz również możliwość dzielenia się wiedzą. „Najlepiej wyjaśnić swoją opinię i poprzeć ją dokumentacją” - mówi Luxton. Linki, które podajesz w celu poparcia dowodów i wiarygodnych artykułów, nie tylko pomagają recenzentowi i twórcy kodu odkrywać różne podejścia, gdy podejmują ostateczną decyzję, ale także wzmacniają ich znajomość programowania.
Pamiętając o tych wskazówkach, pamiętaj również, że recenzowanie to czas na ćwiczenie umiejętności ludzi. „Daj ludziom korzyść z wątpliwości, że pomyśleli o swoim podejściu i wskaż różne możliwości, próbując rozwiać obronę”, mówi Rudder. „Zostawiam komentarze i komentarz podsumowujący - oto, co jest świetne, oto, co można poprawić, oto, co należy zmienić przed połączeniem”.
Dzięki takiemu podejściu nie tylko będziesz chronić bazę kodu przed długiem technologicznym, zagrożeniami bezpieczeństwa i błędami, ale także będziesz budować swój zespół.
