Pamiętam, że za każdym razem, gdy trafiałem do nowego projektu i musiałem po raz pierwszy wystawić kod na Code Review, któremu towarzyszyło kołatanie serca. Od razu nasuwały się myśli o tym, co mogłem poprawić. Zadawałem sobie nieraz pytanie. Czy ten kod będzie wystarczająco dobry, aby trafił do gałęzi rozwojowej? Przecież znam jego niedoskonałości.
Czy dalej boję się pokazywać kod, który wytworzyłem? Teraz już nie. Teraz jest to naturalna część mojej pracy.
A dlaczego? Ponieważ tworząc kod, miałem pewną wizję, założenia i wymagania. Dałem z siebie tyle, na ile pozwala mi wiedza i ograniczenia np. w postaci czasu. Nie mogłem lub nie potrafiłem napisać go lepiej.
Oczywiście. Ktoś inny może widzieć więcej, znać więcej wzorców czy metod refaktoryzacji. Dzięki temu potencjalnie jestem się czegoś nowego nauczyć.
Chciałbym podzielić się z Tobą 4 przydatnymi radami, dzięki którym Code Review sprawi, że staniesz się lepszym programistą 🙂
#1 Ja != Kod
To naturalne, że boimy się krytyki oraz oceny, w stylu „ten kod jest do bani!„. Uważamy, że kod odzwierciedla nasze umiejętności – tak faktycznie MOŻE być. Ale z dużym naciskiem na MOŻE.
Natomiast, kod nie zawsze jest ładny i piękny. Tak po prostu jest. Nie da się lepiej, a jeśli się da, to potrzebowalibyśmy dodatkowego nakładu pracy, który nijak ma się do realizacji celu. Po prostu teraz nie możemy sobie na to pozwolić. Pozostaje on na poziomie „wystarczająco dobry”.
Sam mam kilka (jak nie kilkanaście) prostych narzędzi, stworzonych na kolanie, po to, aby ułatwić mi życie. Gdybym je pokazał innym programistom, mógłbym spodziewać się sporej ilości poprawek. Mógłbym zrobić to lepiej. Natomiast to jest coś, co ma tylko i wyłącznie działać. Realizuje cel, który jest dla mnie ważniejszy niż Clean Architecture dla narzędzia optymalizującego obrazki, który wykorzystuje tylko na swoje potrzeby.
#2 To jest nasz wspólny kod
Pracując jednak w zespole, normalne jest, że te same fragmenty kodu modyfikowane są przez inne osoby. Tak więc aktualny stan kodu to wynik prac różnych ludzi. Staram się w takich projektach propagować bardzo prostą zasadę.
Każda linijka kodu, jest NASZĄ linijką kodu, a nie linijką, którą dodał po pijaku Mateusz 🙂
Jeśli rozbudowuję projekt, to rozbudowuję NASZĄ bazę kodu. Jeśli razem zgodzimy się na przyjęcie mojej zmiany, to razem za nią będziemy odpowiadać. Łatwiej jest wspólnie dbać i rozwijać aplikacje, jeśli nie tworzymy podziału na podstawie autora danego fragmentu. To nasz kod. Jest efektem naszych decyzji, które zostały podjęte w określonym czasie.
Mój kod nie jest już moim kodem.
#3 Otwórz się na „przegląd kodu”
Przez pierwsze 4 lata mojej zawodowej pracy, nie miałem „w standardzie” Code Review. Pomimo uruchomienia kilku projektów, nauki wielu wzorców oraz rozwiązań, ten czas nie był do końca wykorzystany w 100%.
Jako programiści działaliśmy zazwyczaj sami, a czasu na dyskusje było mało. Jedynie kluczowe elementy przegadywaliśmy na szybkiej kawie. Sam też słabo starałem się o to, aby wszystko, co robię, przejrzał ktoś bardziej doświadczony. Wiedza, którą posiadali programiści, nie była propagowana pomiędzy nimi. Coś, co było po prostu na wyciągnięcie ręki – przepadało z każdym kolejnym commitem.
Dopiero później, gdy trafiłem do nowego środowiska, nowej firmy, zmieniło się to diametralnie. Standardem było Code Review. Trochę strachu na początku, ale okazało się, że nie ma tak źle. Mogę wręcz powiedzieć, że w ciągu pół roku, nauczyłem się więcej od kolegów z pracy, niż przez poprzednie 4 lata.
Każde Code Review to szansa na dyskusję, zastanawianie się nad implementacją, ale także uczenie się od innych i poznawanie ich spojrzenia na tworzenie oprogramowania. Każdy z nas ma inną ścieżkę zawodową, którą przeszedł. Pracował w innych projektach, w różnych frameworkach i bibliotekach. To składa się na sumę posiadanego doświadczenia. Jeśli go sami jeszcze nie posiadamy – czerpmy tę wiedzę od innych.
#4 Wyciągnij wnioski i wdróż je w kolejnej iteracji
Pojawiające się uwagi i propozycje innych rozwiązań, które ktoś zostawia Ci na Code Review, polecam sobie notować. Może to być notatka w OneNote czy gdziekolwiek indziej. Mi one pomogły, aby oduczyć się pewnych nawyków. Pamiętałem, że ktoś zwrócił mi uwagę na wykorzystywanie w odpowiedni sposób const i let (gdy tylko pojawiły się w JS), dlatego podczas następnej realizacji zadania miałem to w pamięci. Każda kolejna deklaracja zmiennej nie była już automatyczna, musiałem chwilę się zastanowić, co z nią będę potrzebował zrobić.
To tylko jeden z wielu przykładów, które mogę przytoczyć, natomiast to Code Review pozwoliło mi nauczyć się wielu świetnych sposobów na tworzenie lepszego kodu – pod względem czytelności, wydajności czy szybkości modyfikacji (oczywiście w zależności od potrzeby).
Mam też swoją zasadę. Zanim poproszę inne osoby o review mojego kodu, zaraz po utworzeniu Merge Request / Pull Request albo Review w Crucible, zostaje pierwszym reviewerem mojego kodu. Czyli robię Code Review sam sobie 🙂 To pozwala wyłapać drobne rzeczy, które przypadkowo mogły się wkraść w nasze zmiany. Analizuję wtedy jeszcze raz, cały zmodyfikowany kod – czy ma sens, czy nie da się tego zrobić inaczej, czy jest on zrozumiały, czy wiadomo, co chciałem za jego pomocą przekazać.
Podsumujmy
Chciałbym, abyś zapamiętał z tego newslettera cztery najważniejsze rzeczy:
- Kod to nie Ty. To tylko kod, kilkanaście znaczków.
- Przyjmij uwagi innych osób, to inne spojrzenie na rozwiązywanie problemów.
- Notuj lub pamiętaj wcześniej zgłoszone usprawnienia.
- Bądź swoim pierwszym reviewerem kodu.
Jeśli boisz się pokazać swój kod, masz obawy lub coś Cię blokuje. Daj nam znać, opisz swoją sytuację. Być może będę w stanie Ci pomóc.
