Scalanie wypracowanych zmian z aktualną wersją kodu często odbywa się w efekcie pewnej procedury. Nierzadko w tej procedurze zawiera się pull request oraz code review. Jednak żeby kod nadawał się do pokazania go światu, zwykle staram się wykonywać sekwencję kroków, które mają na celu sprawdzenie wszystkich miejsc, w których coś mogłoby pójść nie tak jakbym sobie tego życzyła.
Piszę „zwykle” i „staram się”, ponieważ daleko mi do ideału i nie zamierzam udawać, że jest inaczej: zdarza mi się o czymś zapomnieć, coś pominąć, czegoś nie wziąć po uwagę. Tym bardziej doceniam kolegów, którzy poświęcają swój czas na solidne przeanalizowanie mojego kodu, ponieważ na tym etapie można wyłapać wiele błędów i lapsusów. Staram się odwdzięczać tym samym, ale code review to temat następnego wpisu z tej serii.
Jak już wyjaśniłam w poprzednim wpisie, pull request (w skórcie PR) to „wniosek” o dołączenie zmian do aktualnej wersji kodu. W przypadku mojego projektu odbywa się to poprzez wypchnięcie moich zmian do zdalnego repozytorium, wskazanie gałęzi, z którą chciałabym scalić swoje zmiany oraz wybranie osób, które zostaną poproszone o code review. W tym wpisie cofam się o krok – do momentu kiedy w mojej ocenie feature albo bugfix jest już zaimplementowany, ale nie utworzyłam jeszcze pull requesta. Co wtedy robię?
Czytam opis wykonywanej funkcjonalności/poprawianego błędu
Kilka razy zdarzyło mi się, że pracowałam usilnie nad pewną funkcjonalnością przez dłuższy czas, mój kod przechodził code review, trafiał do testów i od razu zostawał odrzucony, ponieważ moja implementacja nie spełniała wszystkich założeń wymienionych w opisie historyjki. Bardzo mnie to irytowało, ponieważ przez własne niedopatrzenie skazywałam się na „podwójną robotę” nad tym samym taskiem. Od pewnego czasu staram się wyrobić w sobie nawyk dokładnego czytania opisu i wymagań nie tylko przed czy w trakcie implementowania, ale również po skończonej pracy.
Testuję, testuję, testuję
Często jedna mała zmiana może odbić się szerokim echem w innych funkcjonalnościach i to nie do końca tak, jakbym sobie tego życzyła. Staram się więc „wejść w buty” testera i przeklikać moje zmiany oraz miejsca, na które mój kod może mieć wpływ. Dla przykładu: jeżeli zmieniam jakąś funkcjonalność dla użytkowników w pewnej roli a kod jest współdzielony dla wielu ról, to staram się przetestować zmiany również w pozostałych rolach.
Robię sobie code review
Przed poproszeniem kolegów z zespołu o czytanie mojego kodu, najpierw czytam go sama. Staram się zwracać uwagę na wszystko, na co nie zwróci mi uwagi IDE z ustawieniami projektowymi (a zwraca uwagę np. na niezgodność typów w metodach czy błędy składniowe) oraz narzędzie do pre-commitowania (np. wyłapuje console.logi czy za długie linie): metody, które powinny znaleźć się gdzie indziej niż są, powtórki w kodzie i wiele wiele innych. Dopiero po przeczytaniu swojego kodu mogę zacząć myśleć o puszczeniu go w świat.
Buduję projekt
Na tym etapie sprawdzam czy wszystko co napisałam da się zbudować i czy w projekcie nie ma błędów. Mogę też przebudować cały projekt jednocześnie uruchamiając testy i sprawdzić czy wszystkie przechodzą.
Uzupełniam changelog
To etap, o którym dość często zapominałam: po każdej wrzutce powinnam uzupełnić specjalny plik z rejestrem zmian i wpisać do niego numer zadania z Jira oraz jego tytuł. To bardzo ułatwia pracę osobom, które są odpowiedzialne za wydawanie kolejnych wersji aplikacji oraz scalanie ze sobą kolejnych wydań.
Wybieram branch docelowy
Najczęściej nie jest to problematyczne: z reguły od razu w Jira jest podana wersja naprawy, czyli wydanie z którego wyjściowo utworzyłam swoją gałąź i z którą te zmiany scalam. Czasami jednak, najczęściej na przełomie wydań może się zdarzyć, że miejsce przeznaczenia mojego kodu nie jest do końca ustalone (bo np. testy regresji mają się wydarzyć jutro, a ja nie wiem czy zdążę wykonać zadanie). Wtedy kwestia wyboru brancha docelowego może nie być oczywista.
Wybieram reviewerów
Tutaj również najczęściej sprawa jest dość oczywista: o code review proszę kolegów front-endowców. W zespole mamy jednak również full-stacków, którzy specjalizują się w pewnej tematyce. Zdarza się więc, że poza tradycyjnym front-endowym gronem proszę o rzucenie okiem na kod innych kolegów.
Podobnie rzecz się ma, kiedy razem z programistą back-endowym realizujemy zmiany na jednym branchu, wtedy o code review zwracam się również do kolegów odpowiedzialnych za back-end.
Bonus: zmieniam status w Jira i raportuję pracę
Ten etap ma dopisek bonus, ponieważ najczęściej ma miejsce chwilę po utworzeniu pull requesta, jednak są to czynności bezpośrednio z pull requestem związane. Kiedy moje zmiany przekazywane są do code review, status zadania w Jira należy zmienić na „In review”. Również w Jira powinnam zaraportować godziny przeznaczone na wykonanie tego zadania.
Podsumowanie
Sekwencja czynności wykonywanych przed pull requestem pozwalaja mi wyłapać błędy i niedociągnięcia zarówno w moim kodzie, jak i implementowanej funkcjonalności. Natomiast zdefiniowana checklista bardzo ułatwia zapamiętanie wszystkich niezbędnych do wykonania kroków.