Wprowadzanie zdrowego podejścia do przeglądu kodu do swojego zespołu

„Przegląd kodu” to moment w procesie rozwoju, w którym Ty (jako programista) i Twoi koledzy pracujecie razem i szukacie błędów w ostatnim fragmencie kodu, zanim zostanie on wydany. W takim momencie możesz być autorem kodu lub jednym z recenzentów.

Przeprowadzając przegląd kodu, możesz nie być pewien, czego szukasz. Z drugiej strony, przesyłając recenzję kodu, możesz nie wiedzieć, na co czekać. Ten brak empatii i błędne oczekiwania między obiema stronami mogą wywołać niefortunne sytuacje i przyspieszyć proces, aż zakończy się nieprzyjemnym doświadczeniem dla obu stron.

W tym artykule podzielę się tym, jak można zmienić ten wynik, zmieniając nastawienie podczas przeglądu kodu:

• Jako zespół
• Jako autor
• Jako recenzent

Praca jako zespół

Rozwijaj kulturę współpracy

Zanim zaczniemy, podstawowe znaczenie ma zrozumienie, dlaczego kod musi być przeglądany. Dzielenie się wiedzą i spójność zespołu są korzystne dla wszystkich, jednak jeśli zostanie wykonane ze słabym nastawieniem, przegląd kodu może być bardzo czasochłonnym konsumentem z nieprzyjemnymi wynikami.

Postawa i zachowanie zespołowe powinny uwzględniać wartość nieoceniającej współpracy, której wspólnym celem jest nauka i dzielenie się — niezależnie od czyjegoś doświadczenia.

Uwzględnij recenzje kodu w swoich szacunkach

Pełny przegląd kodu wymaga czasu. Jeśli zmiana trwała tydzień, nie oczekuj, że weryfikacja kodu zajmie mniej niż jeden dzień. To po prostu tak nie działa. Nie próbuj przyspieszać przeglądu kodu ani nie traktuj go jako wąskiego gardła.

Przeglądy kodu są równie ważne jak pisanie samego kodu. Jako zespół pamiętaj, aby uwzględnić przeglądy kodu w swoim przepływie pracy i określić oczekiwania dotyczące tego, jak długo może potrwać przegląd kodu, aby wszyscy byli zsynchronizowani i mieli pewność co do swojej pracy.

Oszczędzaj czas dzięki wytycznym i automatyzacji

Skutecznym sposobem zagwarantowania spójnego wkładu jest zintegrowanie szablonu Pull Request w projekcie. Pomoże to autorowi przesłać zdrowy PR z pełnym opisem. Opis PR powinien wyjaśniać, jaki jest cel zmiany, powód i jak ją odtworzyć. Zrzuty ekranu i linki referencyjne (problem z Git, plik projektu itd.) to ostatnie poprawki do zgłoszenia, które nie wymaga wyjaśnień.

Wykonanie tych wszystkich czynności uniemożliwi wczesne komentarze recenzentów proszących o więcej szczegółów. Innym sposobem na sprawienie, by przeglądy kodu wydawały się mniej skomplikowane, jest użycie linterów w celu znalezienia problemów z formatowaniem kodu i jakością kodu, zanim recenzent w ogóle się w to zaangażuje. Za każdym razem, gdy zobaczysz powtarzający się komentarz podczas procesu recenzji, poszukaj sposobów, aby go zminimalizować (za pomocą lepszych wytycznych lub automatyzacji kodu).

Zostań studentem

Każdy może przeprowadzić przegląd kodu i każdy musi otrzymać przegląd kodu — bez względu na poziom stażu pracy. Otrzymuj wszelkie opinie z wdzięcznością jako okazję do nauki i dzielenia się wiedzą. Traktuj wszelkie opinie jako otwartą dyskusję , a nie reakcję obronną. Jak mówi Ryan Holiday:

„Amator jest defensywny. Profesjonalista uważa, że ​​nauka (a czasami nawet przychodzenie) jest przyjemna; lubią wyzwania i pokory oraz angażują się w edukację jako ciągły i niekończący się proces. (...)”

— Ryan Holiday, Ego jest wrogiem

Zachowaj pokorę, ponieważ w chwili, gdy przestaniesz być studentem, twoja wiedza staje się krucha.

Sztuka doboru recenzentów

Moim zdaniem wybór recenzentów jest jedną z najważniejszych decyzji dla efektywnego i zdrowego przeglądu kodu jako zespołu.

Załóżmy, że Twój kolega przesyła recenzję kodu i decyduje się oznaczyć tagiem „wszystkich”, ponieważ nieświadomie może chcieć przyspieszyć proces, dostarczyć najlepszy możliwy kod lub upewnić się, że wszyscy wiedzą o zmianie kodu. Każdy z recenzentów otrzymuje powiadomienie, a następnie otwiera link PR i widzi wiele osób oznaczonych jako recenzenci. W ich głowach pojawia się myśl „ktoś inny to zrobi”, co prowadzi do zignorowania przeglądu kodu i zamknięcia linku.

Ponieważ nikt jeszcze nie rozpoczął recenzji, Twój kolega przypomni każdemu z recenzentów, aby to zrobili, tj. wywarli na nich presję. Gdy recenzenci zaczną to robić, proces recenzji trwa wiecznie, ponieważ każdy ma swoje zdanie i koszmarem jest osiągnięcie wspólnego porozumienia. W międzyczasie każdy, kto zdecydował się nie przeglądać kodu, jest następnie zasypywany milionami powiadomień e-mail ze wszystkimi komentarzami do recenzji, co powoduje hałas w jego produktywności.

Widzę, że dzieje się to częściej, niż bym chciał: pull requesty z grupą osób oznaczonych jako recenzenci i kończące się, jak na ironię, nieproduktywnym przeglądem kodu.

Istnieje kilka typowych skutecznych procedur wyboru recenzentów: Możliwym procesem jest wybranie dwóch do trzech współpracowników, którzy znają kod i poproszenie ich o zostanie recenzentami. Innym podejściem, wyjaśnionym przez zespół Gitlab, jest łańcuchowy przepływ recenzji, w którym autor wybiera jednego recenzenta, który wybiera innego recenzenta, dopóki co najmniej dwóch recenzentów nie zgodzi się z kodem. Niezależnie od wybranego przepływu unikaj zbyt wielu recenzentów . Umiejętność ufania osądowi kodeksu swoich kolegów jest kluczem do przeprowadzenia skutecznego i zdrowego przeglądu kodu.

Miej empatię

Wykrywanie fragmentów kodu w celu poprawy to tylko część udanego przeglądu kodu. Równie ważne jest przekazywanie tych informacji zwrotnych w zdrowy sposób poprzez okazywanie empatii współpracownikom.

Przed napisaniem komentarza pamiętaj, aby postawić się na miejscu innych. Podczas pisania łatwo jest zostać źle zrozumianym, więc przejrzyj własne słowa przed ich wysłaniem. Nawet jeśli rozmowa zaczyna być brzydka, nie pozwól, aby wpłynęła na ciebie — zawsze zachowaj szacunek. Dobre mówienie do innych nigdy nie jest złą decyzją.

Wiedzieć, jak iść na kompromis

Jeśli dyskusja nie zostanie szybko rozwiązana, zabierz ją do osobistej rozmowy lub czatu. Przeanalizujcie wspólnie, czy jest to temat wart sparaliżowania aktualnej prośby o zmianę, czy też można go rozwiązać w innym.

Bądź elastyczny, ale pragmatyczny i umie zrównoważyć wydajność (dostarczanie) i skuteczność (jakość). To kompromis, który należy osiągnąć jako zespół. W takich momentach lubię myśleć o przeglądzie kodu jako o iteracji, a nie o ostatecznym rozwiązaniu. W następnej rundzie zawsze jest miejsce na poprawę.

Recenzje kodów osobistych

Zebranie autora i recenzenta w stylu programowania w parach może być bardzo skuteczne. Osobiście wolę to podejście, gdy przegląd kodu obejmuje złożone zmiany lub istnieje możliwość wymiany dużej ilości wiedzy. Pomimo tego, że jest to przegląd kodu offline, dobrym zwyczajem jest zostawianie komentarzy online na temat podjętych dyskusji, zwłaszcza gdy po spotkaniu trzeba wprowadzić zmiany. Jest to również przydatne, aby inni recenzenci online byli na bieżąco.

Ucz się na podstawie wyników przeglądu kodu

Kiedy przegląd kodu przeszedł wiele zmian, trwał zbyt długo lub miał już za dużo dyskusji, zbierz swój zespół i przeanalizuj przyczyny oraz jakie działania można z niego podjąć. Gdy przegląd kodu jest złożony, podzielenie przyszłego zadania na mniejsze zadania ułatwia każdą recenzję kodu.

Gdy luka w doświadczeniu jest duża, przyjęcie programowania w parach jest strategią o niesamowitych rezultatach — nie tylko w zakresie dzielenia się wiedzą, ale także współpracy i komunikacji w trybie offline. Niezależnie od wyniku, zawsze staraj się stworzyć zdrowy, dynamiczny zespół z jasnymi oczekiwaniami.

Jako autor

Jednym z głównych problemów podczas pracy nad przeglądem kodu jako autora jest zminimalizowanie zaskoczenia recenzenta podczas czytania kodu po raz pierwszy. To pierwszy krok do przewidywalnego i płynnego przeglądu kodu. Oto jak możesz to zrobić.

Nawiąż wczesną komunikację

Nigdy nie jest złym pomysłem, aby porozmawiać z przyszłymi recenzentami, zanim zaczniesz kodować za dużo. Zawsze, gdy jest to wkład wewnętrzny lub zewnętrzny, możesz wspólnie udoskonalić lub trochę zaprogramować w parach na początku rozwoju, aby omówić rozwiązania.

Nie ma nic złego w proszeniu o pomoc na pierwszym etapie. W rzeczywistości wspólna praca poza przeglądem jest pierwszym ważnym krokiem, aby zapobiec wczesnym błędom i zagwarantować wstępne porozumienie. W tym samym czasie Twoi recenzenci dowiadują się o przyszłej ocenie kodu, którą należy przeprowadzić.

Postępuj zgodnie z wytycznymi

Przesyłając pull request do sprawdzenia, pamiętaj, aby dodać opis i postępować zgodnie z wytycznymi. Dzięki temu recenzenci nie będą tracić czasu na zrozumienie kontekstu nowego kodu. Nawet jeśli Twoi recenzenci już wiedzą, o co chodzi, możesz również wykorzystać tę okazję jako sposób na poprawę swoich umiejętności pisania i komunikacji.

Bądź swoim pierwszym recenzentem

Widzenie własnego kodu w innym kontekście pozwala znaleźć rzeczy, których byś przegapił w swoim edytorze kodu. Zrób przegląd kodu własnego kodu, zanim poprosisz współpracowników. Miej nastawienie recenzenta i naprawdę przejrzyj każdy wiersz kodu.

Osobiście lubię dodawać adnotacje do własnych recenzji kodu, aby lepiej kierować moimi recenzentami. Celem tutaj jest zapobieganie komentarzom związanym z możliwym brakiem uwagi i upewnienie się, że postępujesz zgodnie z wytycznymi dotyczącymi wkładu. Postaraj się przesłać recenzję kodu tak, jak chcesz ją otrzymać.

Bądź cierpliwy

Po przesłaniu recenzji kodu nie wskakuj od razu do nowej prywatnej wiadomości, prosząc recenzentów o „popatrz, to zajmuje tylko kilka minut” i pośrednio pragnąc tego emoji z kciukiem w górę. Próba ponaglania współpracowników do pracy nie jest zdrowym nastawieniem. Zamiast tego zaufaj przepływowi pracy współpracowników, ponieważ ufają, że prześlesz dobrą recenzję kodu. Tymczasem poczekaj, aż wrócą do Ciebie, gdy będą dostępne. Nie traktuj recenzentów jako wąskiego gardła. Pamiętaj o cierpliwości, ponieważ trudne rzeczy wymagają czasu.

Bądź słuchaczem

Po przesłaniu przeglądu kodu pojawią się komentarze, pytania zostaną zadane i zostaną zaproponowane zmiany. Złotą zasadą jest, aby nie traktować żadnych informacji zwrotnych jako osobistego ataku. Pamiętaj, że każdy kod może skorzystać z zewnętrznej perspektywy .

Nie patrz na swoich recenzentów jak na wroga. Zamiast tego poświęć ten moment na odłożenie na bok swojego ego, zaakceptuj, że popełniasz błędy i bądź otwarty na uczenie się od kolegów, aby następnym razem móc wykonywać lepszą pracę.

Jako recenzent

Planuj z wyprzedzeniem

Kiedy zostaniesz poproszony o zostanie recenzentem, nie przerywaj od razu. To częsty błąd, który cały czas widzę. Przeglądanie kodu wymaga Twojej pełnej uwagi, a za każdym razem, gdy zmieniasz kontekst kodu, zmniejszasz swoją produktywność, marnując czas na ponowne kalibrowanie uwagi. Zamiast tego planuj z wyprzedzeniem, przydzielając przedziały czasowe swojego dnia na przeglądy kodu.

Osobiście wolę robić przeglądy kodu z samego rana lub po obiedzie przed podjęciem jakichkolwiek innych zadań. To działa najlepiej dla mnie, ponieważ mój mózg jest wciąż świeży bez wcześniejszego kontekstu kodu, od którego można się wyłączyć. Poza tym, kiedy skończę z recenzją, mogę skupić się na własnych zadaniach, podczas gdy autor może ponownie ocenić kod na podstawie opinii.

Bądź wspierający

Gdy pull request nie jest zgodny z wytycznymi dotyczącymi wkładu, okaż wsparcie — zwłaszcza dla nowicjuszy. Potraktuj ten moment jako okazję do pokierowania autorem w celu poprawy jego wkładu. Tymczasem spróbuj zrozumieć, dlaczego autor nie zastosował się do wytycznych w pierwszej kolejności. Być może jest miejsce na ulepszenia , o których wcześniej nie wiedziałeś.

Sprawdź oddział i uruchom go

Przeglądając kod, uruchom go na własnym komputerze — zwłaszcza, gdy obejmuje on interfejsy użytkownika. Ten nawyk pomoże ci lepiej zrozumieć nowy kod i dostrzec rzeczy, które możesz przegapić, jeśli właśnie używasz domyślnego narzędzia porównywania w przeglądarce, które ogranicza zakres przeglądu do zmienionego kodu (bez pełnego kontekstu, jak w edytorze kodu) .

Zapytaj przed założeniem

Kiedy czegoś nie rozumiesz, nie bój się tego powiedzieć i zadawać pytań. Kiedy pytasz, pamiętaj, aby najpierw przeczytać otaczający kod i unikać robienia założeń.

Większość pytań pasuje do tych dwóch rodzajów kategorii:

1. Pytania „Jak”?
   Jeśli nie rozumiesz, jak coś działa lub co robi, oceń z autorem, czy kod jest wystarczająco jasny. Nie myl prostego kodu z ignorancją. Istnieje różnica między kodem, który jest trudny do odczytania, a kodem, którego nie znasz. Bądź otwarty na naukę i używanie nowej funkcji języka, nawet jeśli nie znasz jej jeszcze dogłębnie. Jednak używaj go tylko wtedy, gdy upraszcza bazę kodu.
2. Pytania „dlaczego”?
   Jeśli nie rozumiesz „dlaczego”, nie bój się sugerować skomentowania kodu, zwłaszcza jeśli jest to przypadek brzegowy lub naprawa błędu. Kod powinien być zrozumiały, jeśli chodzi o wyjaśnienie, co robi. Komentarze są uzupełnieniem wyjaśnienia, dlaczego kryje się za pewnym podejściem. Wyjaśnienie kontekstu jest bardzo cenne, jeśli chodzi o łatwość konserwacji i uchroni kogoś przed usunięciem bloku kodu, który uważał za bezużyteczny. (Osobiście lubię komentować kod, dopóki nie poczuję się bezpiecznie, że później go zapomnę.)

Konstruktywna krytyka

Gdy znajdziesz fragment kodu, który Twoim zdaniem powinien zostać poprawiony, zawsze pamiętaj, aby docenić wysiłek autora włożony w projekt i wyrazić siebie w otwarty i przejrzysty sposób.

• Otwarte dyskusje.
  Unikaj formalizowania swojej opinii jako polecenia lub oskarżenia, takiego jak „Powinieneś…” lub „Zapomniałeś…”. Wyraź swoją opinię w formie otwartej dyskusji, a nie obowiązkowej prośby. Pamiętaj o komentowaniu kodu, a nie autora. Jeśli komentarz nie dotyczy kodu, nie powinien należeć do przeglądu kodu. Jak powiedziałem wcześniej, bądź wspierający. Używanie biernego głosu, mówienie w liczbie mnogiej, wyrażanie pytań lub sugestii to dobre podejścia do podkreślenia empatii wobec autora.
  

Zamiast „Wyodrębnij tę metodę stąd…” wybierz „Ta metoda powinna zostać wyodrębniona…” lub „Co myślisz o wyodrębnianiu tej metody…”

• Bądź jasny.
  Informacja zwrotna może być łatwo błędnie zinterpretowana, zwłaszcza jeśli chodzi o wyrażenie opinii zamiast dzielenie się faktem lub wskazówką. Zawsze pamiętaj, aby usunąć to od razu w swoim komentarzu.

Niejasne: „Ten kod powinien być…”.

Opinia: „Uważam, że ten kod powinien być…”

Fakt: „Zgodnie z [naszymi wytycznymi] ten kod powinien być…”.

• Wyjaśnij dlaczego.
  To, co dla ciebie jest oczywiste, może nie być dla innych. Nigdy nie jest za dużo wyjaśnianie motywacji twojej opinii, więc autor nie tylko rozumie, jak coś zmienić, ale także jakie korzyści z tego płyną.

Opinia: „Wierzę, że ten kod może być…”

Wyjaśniono: „Wierzę, że ten kod mógłby być (…), ponieważ poprawi to czytelność i uprości testy jednostkowe”.

• Podaj przykłady.
  Udostępniając funkcję kodu lub wzorzec, których autor nie jest zaznajomiony, uzupełnij swoją sugestię odnośnikiem jako wskazówką. Jeśli to możliwe, wyjdź poza dokumenty MDN i udostępnij fragment lub działający przykład dostosowany do bieżącego scenariusza kodu. Gdy pisanie przykładu jest zbyt skomplikowane, okaż wsparcie i zaoferuj pomoc osobiście lub przez rozmowę wideo.

Oprócz powiedzenia czegoś takiego jak „Korzystanie z filtra pomoże nam [motywacja]”, powiedz także: „W tym przypadku może to być coś w stylu: [fragment kodu]. Możesz sprawdzić [przykład w Finder.js]. Jeśli masz jakiekolwiek wątpliwości, śmiało pisz do mnie na Slacku.

• Bądź rozsądny.
  Jeśli ten sam błąd zostanie popełniony wiele razy, wolę pozostawić tylko jeden komentarz na jego temat i pamiętać, aby autor sprawdził go również w innych miejscach. Dodanie zbędnych komentarzy powoduje tylko szum i może być nieproduktywne.

Zachowaj koncentrację

Unikaj proponowania zmian w kodzie niezwiązanych z bieżącym kodem. Zanim zasugerujesz zmianę, zadaj sobie pytanie, czy w danym momencie jest to absolutnie konieczne. Ten rodzaj sprzężenia zwrotnego jest szczególnie powszechny w przypadku refaktorów. To jeden z wielu kompromisów między wydajnością a skutecznością, których musimy dokonać jako zespół.

Jeśli chodzi o refaktory, osobiście wolę małe, ale skuteczne ulepszenia . Są one łatwiejsze do przeglądania i istnieje mniejsze prawdopodobieństwo wystąpienia konfliktów kodu podczas aktualizowania gałęzi z gałęzią docelową.

Ustaw oczekiwania

Jeśli zostawisz recenzję kodu w połowie ukończoną, poinformuj o tym autora, aby oczekiwania czasowe były pod kontrolą. Na koniec poinformuj również autora, czy zgadzasz się z nowym kodem, czy też chciałbyś ponownie przejrzeć go później.

Zanim zatwierdzisz przegląd kodu, zadaj sobie pytanie, czy czujesz się komfortowo, jeśli chodzi o możliwość dotknięcia tego kodu w przyszłości. Jeśli tak, to znak, że przeszedłeś pomyślnie przegląd kodu!

Naucz się odmawiać przeglądu kodu

Chociaż nikt tego nie przyznaje, czasami trzeba odmówić recenzji kodu. W momencie, gdy zdecydujesz się zaakceptować przegląd kodu, ale spróbujesz go pospieszyć, jakość projektu jest zagrożona, a także sposób myślenia Twojego zespołu.

Kiedy zgadzasz się na przejrzenie czyjegoś kodu, ta osoba ufa twoim możliwościom — to zobowiązanie. Jeśli nie masz czasu, aby być recenzentem, po prostu powiedz nie swoim kolegom. Naprawdę to mam na myśli; nie pozwól swoim współpracownikom czekać na przegląd kodu, który nigdy nie zostanie wykonany. Pamiętaj, aby komunikować się i mieć jasne oczekiwania . Bądź szczery ze swoim zespołem i — jeszcze lepiej — ze sobą. Cokolwiek wybierzesz, rób to zdrowo i dobrze.

Wniosek

Biorąc pod uwagę wystarczającą ilość czasu i doświadczenia, przeprowadzanie przeglądów kodu nauczy Cię znacznie więcej niż tylko wiedzy technicznej. Nauczysz się dawać i otrzymywać informacje zwrotne od innych, a także podejmować decyzje z większą ilością przemyśleń.

Każdy przegląd kodu jest okazją do rozwoju społecznościowego i indywidualnego. Nawet poza przeglądami kodu pamiętaj, aby pielęgnować zdrowy sposób myślenia, aż do dnia, w którym stanie się to naturalne dla Ciebie i Twoich współpracowników. Dzielenie się czyni nas lepszymi!

Dalsze czytanie na SmashingMag:

• Współpraca: jak projektanci i programiści mogą komunikować się w celu tworzenia lepszych projektów
• Lepsza współpraca dzięki zaangażowaniu projektantów w proces przeglądu kodu
• Jakich podcastów powinni słuchać projektanci stron internetowych i programiści?
• Jak stworzyć idealne CV dla programistów internetowych