Code review jako dźwignia w Twojej karierze
Oprogramowanie codziennie się zmienia. Kod źródłowy, który je tworzy, wymaga inspekcji. Dzisiaj pogadamy o tym, jak postępuje Dziarski Dev, czyli dlaczego musisz robić code review, nawet jeśli jesteś nowym członkiem zespołu.
Wyjaśnijmy to sobie. Dobrze zrobione code review wymaga odpowiedniego poziomu skupienia. W tym czasie MUSISZ odłożyć inne rzeczy na drugi plan i skupić się na kodzie, który przeglądasz. Tylko w ten sposób będziesz miał jakieś szanse na zrobienie tego jakościowo.
Linijka po linijce. Klasa po klasie. Po to, żeby przygotować jakościowy feedback dla autora zmian.
I tu pojawia się problem
Właśnie to wejście w tryb skupienia wymaga sporego zaangażowania. Koniecznie musisz zawiesić inne czynności i swoje aktualne zadania na bok, na rzecz przejrzenia zmian członka zespołu. Po to, aby zrobić dobre code review. I wiem, że może to być niesamowicie trudne. Oj może…
Mnie też się nie chcę.
Uwielbiam zaczynać pracę przed wszystkimi i w tym czasie na spokojnie, na swoich zasadach ruszyć ze swoim aktualnym zadaniem. Bez rozpraszaczy, bez pytań, ze świadomością, że w pracy jeszcze nikogo nie ma albo przynajmniej tylko część zespołu dopiero zaczyna.
Przynajmniej tak było kiedyś, kiedy pracowałem w mniejszym zespole, a moja rola różniła się od obecnej. No ale musiałem wbić sobie do głowy, że poranki muszę poświęcać na code review.
Dlaczego?
Bo pull requesty, mają wyższy priorytet niż każdy inny mój task, który jest w trakcie.
Dlaczego?
Bo to zmiany, które są GOTOWE. Przynajmniej z założenia, bo wiadomo, jak jest, autor zmian mógł dostarczyć niskiej jakości kod, który może wymagać dodatkowych zmian, ale nadal jest to zadanie bliższe ukończenia niż to, nad którym aktualnie pracujesz.
Niesamowicie trudne jest, aby wyrobić w sobie nawyk (w zasadzie to przestrzeganie obowiązku) poświęcania poranka na przeglądy kodu, ale jest w tym kilka fajnych benefitów.
Ale zanim argumenty. Dlaczego poranek?
To akurat moja fanaberia. Równie dobrze możesz robić to o każdej innej porze. Liczy się fakt, że to robisz.
Code review i Twoje profity
Po pierwsze…
Jesteś na bieżąco ze zmianami w projekcie. Jak wspomniałem na początku. Kod zmienia się codziennie. Projekt ewoluuje każdego dnia i nie jesteś w stanie wiedzieć, nad czym pracują aktualnie wszystkie inne osoby. Przeglądy kodu w tym pomagają, nawet jeśli nie przeglądasz wszystkich PR’ów.
Co więcej, znajomość zmian pozwoli Ci na lepsze podejmowanie decyzji. To akurat proste, bo to dzięki znajomości różnych części projektu pod względem kodu.
Po drugie
Budujesz w pewnym sensie swoją markę w zespole. Jeśli jesteś czynnym uczestnikiem code review inni będą Cię podświadomie postrzegać jako osobę aktywną i zaangażowaną – nawet jeśli nie mówią o tym wprost. Droga do tego jest raczej długa, ale każda z dobrych aktywności dokłada do tego cegiełkę.
Po trzecie
Poznajesz innych programistów. Mam tu na myśli ich umiejętności, zaangażowanie, sposób komunikacji a co najważniejsze przyjmowanie innego punktu widzenia. Przecież podczas dobrego code review pojawia się sporo propozycji zmian czy zwracania uwagi na luki, których dopuścił się autor. Swoją drogą, z tym ostatnim niektórzy mają problem (doświadczyłem już tego wielokrotnie), ale to dobra baza do rozwoju.
Po czwarte
Sam uczysz się komunikować. Pojawia się dyskusja. Z jednej strony jesteś Ty, a z drugiej autor kodu. Zdarza się, że musisz przekonać autora do swoich racji i ich poprawności. Musisz opisać swój ciąg myślowy. A to wymaga praktyki. Zwykłe napisanie _„Weź, to zmień, bo mi się nie podoba”_nikogo do niczego (raczej) nie przekona. Powinieneś odwoływać się do ogólnoznanych dobrych praktyk. Każda dodany przez Ciebie komentarz, który wpłynął na zmiany w PR, buduje Twoją umiejętność komunikacji i umacnia jednocześnie Twoją wiedzę, bo czasami musisz coś dodatkowo zweryfikować.
O podobnych tematach możesz poczytać na moim mailingu
Od jakiegoś czasu regularnie wysyłam treści związane z byciem Dziarskim Devem. Moim celem jest pokazanie jak stać się istotniejszym elementem swojego zespołu i w efekcie być bliżej kluczowych decyzji.
✅ Bez lania wody.
Wpadnij na stronę, gdzie dokładniej opisałem co i jak.
👉 dziarskidev.pl
Co do trzeciego argumentu
Jeśli wiesz jakimi umiejętnościami dysponują inni (widzisz to po wyprodukowanym przez nich kodzie), oznacza to, że możesz stwierdzić (wstępnie), jak powinieneś z nimi rozmawiać (czy w ogóle powinieneś) i jak bardzo oni mogą Ci pomóc w codziennej pracy.
No bo jeśli ktoś notorycznie tworzy PR, którego kod dostaje po kilkadziesiąt komentarzy, to trudno założyć, że od tej osoby czegoś się nauczysz, prawda?
Jestem juniorem. Czy powinienem przeglądać zmiany seniora?
Oczywiście. Jeszcze jak! Ale z pokorą. Dużą dawką pokory.
Ogólnie rzecz biorąc to świetna okazja do zrozumienia sposobu myślenia kogoś z większym doświadczeniem. A to spory benefit.
W moim zespole PR musi zaakceptować dwóch programistów, ale zawsze udział w code review może wziąć kilka osób. Zakładam, że w Twoim zespole możesz dołączyć się jako opcjonalny recenzent.
Jeśli nie czujesz się na siłach, aby być jednym z głównych recenzentów, to po prostu bądź tą dodatkową, opcjonalną osobą (dołącz, gdy uzbiera się ta wymagana dwójka). Jeśli jakaś konstrukcja jest dla Ciebie niezrozumiała – pytaj. Wcześnie jednak zadaj sobie pytanie, czy to o co chcesz zapytać, nie jest zbyt trywialne.
Dobra praktyka
Pamiętaj, że każda aktywność podczas code review jest dostrzegalna przez zespół, a co ważniejsze przez liderów.
Wiem, co mówię.
Dlatego, jeśli przeglądasz czyjeś zmiany (na zasadzie ich luźnego przejrzenia), dołączaj jako recenzent. Nawet gdy nie jesteś pewny, że dodasz jakiś komentarz. Pokaż innym, że uczestniczysz w procesie.
Dopiero dołączyłeś do zespołu?
Jeśli jesteś świeżo co upieczonym członkiem zespołu to dołącz do code review jak najszybciej i wyrób w sobie nawyk porannego (moim zdaniem to najlepsza pora) code review. Przyspieszy to Twój proces wdrażania się do projektu. Nawet jeśli nie rozumiesz jeszcze wszystkich zmian to każde takie review zwiększy o 1% Twoje poczucie pewności w projekcie. Serio, serio.
Jakie są moje praktyki?
Zaczynam od zrozumienia zadania. Otwieram Jirę staram sie zrozumieć jego cel i zmiany, których wymaga.
Przeglądam kod pod względem czystości. Najczęściej programiści podczas code review skupiają się tylko na tym aspekcie. To ogromny błąd. Nie tylko o to tu chodzi.
(!) W przypadku poważniejszych zmian pobieram gałąź ze zmianami. Odpalam aplikację i czasami zdarza mi się debugować zmiany. Czasami trudno jest po prostu oglądać zmiany w Bitbucket. Kod w IDE jest znacznie łatwiejszy do przeglądania. Szczególnie jeśli zmian jest więcej.
Zwracam uwagę na powiązania pomiędzy klasami. Może da się tutaj coś zmienić?
Zdecydowanie muszę zrozumieć kontekst zmian. Jeśli coś jest dla mnie niezrozumiałe, to po prostu pytam o to autora.
Jeśli jakaś konstrukcja jest źle napisana, ale wprowadzenie poprawnego podejścia wymaga sporego nakładu pracy, wtedy zdarza mi się proponować stworzenia zadania, które te zmiany wprowadzi w przyszłości. Linkujemy to zadanie w komentarzu do PR. Co więcej, to zadanie zawiera, również odnośnik do PR.
Jeśli coś wyjaśniłem poza PR (czat, rozmowa), wtedy proszę go o dodanie komentarza z ustaleniami. To pomoże w przyszłości, jeśli, ktoś wróci do tego PR.
WYMAGAM, aby autor dodał opis wprowadzonych zmian w PR. Jasne, widzę kod, ale chcę wiedzieć wysokopoziomowo co zostało wprowadzone. To ułatwia zadanie recenzentom.
Staram się (o ile to możliwe) przejrzeć wszystkie zmiany w konkretnym PR przy jednym podejściu, aby autor otrzymał wszystkie moje opinie w jednym momencie. To pozwoli mu optymalniej wprowadzić zmiany.
Ile czasu spędzam na code review?
W moim przypadku w zależności od ilości pracy spędzam nad nim około godziny (czasami do dwóch). Tyle czasu potrzebuję, aby przejść przez powyższe punkty. Z tym że wynika to z tego, że jestem liderem technicznym.
Spokojnie możesz zejść do czasu około 30 minut do godziny. Chodzi o to, żeby znaleźć złoty środek między code review a Twoimi zadaniami.
A na koniec polecam Ci poniższą książkę, jeśli (o dziwo!) nie masz jej jeszcze na swojej półce. Poniższy link jest linkiem afiliacyjnym. Jeśli zdecydujesz się na zakup, ja dostanę prowizję.
Helion – Czysty kod. Podręcznik dobrego programisty
Jest to wpis oparty o jednego z mailu, którego jakiś czas temu wysłałem do subskrybentów mojego mailingu Dziarski Dev. Jeśli jesteś zainteresowany podobnymi tematami sprawdź stronę dziarskidev.pl.
