6 rad dla juniora od senior frontend developera

Pierwsze lata pracy jako programista zazwyczaj bywają trudne, a prężnie rozwijający się ekosystem JavaScript z pewnością w tym nie pomaga. Mierzenie się ze stale pojawiającymi się na nowo problemami, bibliotekami i frameworkami, może być przytłaczające. Warto jednak trzymać się celu, jaki powinien przyświecać każdemu, niezależnie od wieku i doświadczenia. Tym celem, w moim przekonaniu, powinno być doskonalenie umiejętności i poszerzanie wiedzy.

Chciałbym podzielić się kilkoma cennymi radami, o których sam nie miałem wcześniej pojęcia, przez co pracując przy moich pierwszych komercyjnych projektach musiałem nabyć tę wiedzę ‘’the hard way’’.

Łukasz Romanowicz. Senior Frontend Developer, a także Team Leader w Divante. Full-Stack Developer działający w branży od ponad 9 lat, pasjonat automatyzacji, IoT oraz amerykańskiej motoryzacji. Fanatyk testów jednostkowych, a także kontrybutor Open Source. Maintainer Vue Storefront. W pogoni za lepszym kodem przemierza niezmierzone połacie języków, frameworków, bibliotek i narzędzi.

Code review

Najszybszą metodą na znalezienie luk w swojej wiedzy i w kodzie jest solidny code review oraz wyciąganie z niego odpowiednich wniosków. Proces ten polega na przejrzeniu kodu przez innego programistę, w celu wyłapania niespójności i błędów wszelkiego rodzaju. Głównym celem projektowym code review jest utrzymywanie jakości kodu na wysokim poziomie, przy jednoczesnym rozpowszechnianiu w zespole informacji na temat zachodzących w nim zmianach, co bezpośrednio wpływa na rozwój współpracowników.

Wartym uwagi jest fakt, że code review może (a nawet powinien) być wykonywany przez programistów o zróżnicowanym stopniu zaawansowania – ci bardziej doświadczeni znajdują z reguły więcej błędów i niedociągnięć, natomiast dla tych mniej doświadczonych będzie to świetna okazja do nabycia dobrych praktyk (a i niejednokrotnie sami coś wynajdą, o czym regularnie przekonuję się sam).

Z początkiem pracy liczba zwracanych zadań do poprawy i komentarzy do naszego kodu może być demotywująca, ale w żadnym razie nie należy się tym przejmować! Każdy kiedyś zaczynał, dlatego drobne niedopatrzenia czy błędy to rzecz całkowicie naturalna. Najważniejszą kwestią jest zrozumienie, z jakiego powodu dany kawałek kodu wymaga zmiany. Jeśli nie jesteś w stanie zrozumieć przyczyny, zapytaj osobę wykonującą code review o wyjaśnienia.

Zdecydowanie najgorszym działaniem w tym przypadku jest powtarzanie tych samych błędów bez większego namysłu. Nie tylko autor kodu będzie miał gorszy dzień z powodu nagminnego poprawiania tego samego zadania, ale również osoba wykonująca CR ze względu na wielokrotne wytykanie tych samych pomyłek.

No więc jak przygotować się do code review, aby uniknąć znacznej liczby błędów? Odpowiedź wydaje się dziecinnie prosta, choć praktyka najczęściej pokazuje, że nie każdy o niej pamięta. Zanim zdecydujesz się oddać wykonane zadanie, spróbuj dokonać CR własnego kodu. Dokładnie go przejrzyj, zadając sobie pytania: ‘’Jakie potencjalne zastrzeżenia mogłaby mieć osoba wykonująca CR?’’, ‘’Jakie błędy najczęściej popełniam?’’ lub chociażby ‘’Czy przypadkiem nie zostawiłem fragmentu jakiegoś kodu w miejscu, w którym nie powinien się on ostatecznie znaleźć?’’.

Dokumentacja to skarbnica wiedzy

Doświadczony programista jest w stanie dostrzec możliwości i funkcje gotowej biblioteki (lub innego komponentu projektu) na podstawie kodu źródłowego. Zajmuje to jednak mnóstwo czasu i zazwyczaj dużo szybciej można tę wiedzę pozyskać z dokumentacji technicznej.

Ten niedoceniony i zwykle niechętnie tworzony komponent projektowy, potrafi niejednokrotnie zaoszczędzić dużo czasu, energii i nerwów, pod warunkiem, że dane tam zawarte są dobrze opisane oraz aktualne. Dodatkowymi zaletami regularnego czytania dokumentacji, w szczególności przy korzystaniu z projektów Open Source, są uwagi dotyczące dobrych praktyk, świadomość funkcji dostępnych w używanych bibliotekach oraz wiedza, co nowego zostało zmienione od ostatnio zainstalowanej wersji (co często bywa bodźcem do aktualizacji danej paczki).

Komunikacja w zespole a samodzielność

W swojej karierze zawodowej spotkałem wielu, nierzadko bardzo doświadczonych programistów, żyjących w przekonaniu, że prawdziwy specjalista rozwiązuje wszystkie problemy i zadania całkowicie sam. Moim zdaniem miejsce takich ludzi, jest co najwyżej w zawodzie Freelancera, a nie w dobrze prosperującym zespole programistycznym. Zadawanie pytań nie jest żadną ujmą, a wręcz pożądanym działaniem. Dzięki temu doskonali się wiedzę w zespole oraz integruje ich członków. Nierzadko krótkim pytaniem można zainicjować ciekawą i owocną dyskusję.

Nadmierna ilość oraz mizerna jakość zadawanych pytań może jednak obrócić się na niekorzyść pytającego. Przede wszystkim należy wystrzegać się pytań, na które odpowiedzi uzyskać można samemu w zaledwie kilka minut – czy to w Internecie, czy w dokumentacji/kodzie projektu. W dalszej kolejności starajmy się formułować pytania precyzyjnie, podając przykłady wypróbowanych przez siebie rozwiązań.

Często możesz spotkać się z brakiem odpowiedzi na zadawane pytania, jednak nie należy się tym zrażać. Może to być spowodowane wieloma przyczynami. Przykładami mogą być zbyt duża ilość czasu, jaką należy przeznaczyć na sformułowanie właściwej odpowiedzi, czy brak w zespole osoby dysponującej odpowiednimi możliwościami, czy wiedzą, aby rozwiązać określony problem. W takim przypadku należy podjąć kolejne próby samodzielnie.

Jeśli napotkamy ścianę nie do przejścia, najlepiej bezpośrednio poprosić doświadczonego kolegę lub przełożonego o pomoc, lub ewentualnie zrobić ‘’krok w tył’’ i rozważyć alternatywne rozwiązania problemu aniżeli dalej dążyć w kierunku, który został obrany na początku.

Ciekawość to pierwszy stopień do wejścia na wyższy poziom

Dobrego programistę można poznać po tym, że nie tylko umie zastosować dostarczane przez bibliotekę/framework funkcje, ale również rozumie, jak są one zbudowane. Warto też mieć na uwadze fakt, że w trakcie większości rozmów rekrutacyjnych do firm, znanych z dobrej jakości kodu, można zostać zapytanym o takie szczegóły. Poza pozostawieniem po sobie dobrego wrażenia w oczach potencjalnego pracodawcy, taka wiedza pozwala również na podejmowanie lepszych decyzji przy implementacji funkcji, optymalizowanie kodu oraz na efektywniejsze debugowanie problemów, schodząc do najniższego poziomu.

Spotykając się z kawałkiem nieznanego oprogramowania warto czasem nad nim dłużej przystanąć i zadać sobie pytanie: ‘’Jak to właściwie działa?’’ zamiast bezkrytycznie użyć, sprawdzić, czy działa i zapomnieć.

Specjalizacja, a człowiek orkiestra

Zakres umiejętności w IT może mieć dwa ekstrema. Jednym z nich jest specjalizacja w wąskim zakresie technologicznym (np. React). Taka osoba jest prawdziwym wymiataczem w swojej dziedzinie, jednak gdy przychodzi zrobić coś poza nią, zazwyczaj odmawia wykonania zadania i deleguje je komuś innemu. Przeciwnym biegunem jest natomiast osoba znająca się po trochu na wszystkim, przez co wszystkie zadania zajmują jej dużo czasu, a efekt końcowy (choć działający), mógłby być znacznie ulepszony.

Osobiście sugeruję specjalizację w konkretnej dziedzinie, przy jednoczesnym nie zamykaniu się na wszelkie inne elementy systemów IT. Mając choć trochę doświadczenia w budowie API, ITsec czy bazach danych będziemy znali dużo szersze spektrum problemu, co pozwoli nam na dokonywanie lepszych decyzji, co zarazem stanowi kolejne bodźce do rozwoju.

Kilka słów o kopiowaniu kodu

Kopiowanie kodu jest bardzo dobre, jak i bardzo złe, w zależności od sytuacji oraz tego, co z kodem zrobimy po jego wklejeniu. Kod skopiowany z dokumentacji technicznej jest w większości przypadków dobrej jakości i stosuje się do zasad dobrego programowania (oczywiście niechlubne wyjątki często się zdarzają). W serwisach wymiany informacji dla programistów jak np. StackOverflow z jakością kodu, szczególnie w niszowych pytaniach, bywa niestety różnie.

W przypadku trudności oceny jakości rozwiązania, warto zerkać na inne odpowiedzi oraz komentarze pod nimi, nie uwzględniając wyłącznie liczby punktów, uzyskanych od innych użytkowników. Niezależnie od jakości kopiowanego kodu, zawsze należy dostosować go do standardów programowania w miejscu docelowym. Pamiętajmy o dobrym nazewnictwie zmiennych, formatowaniu kodu i refaktoryzacji tego obszaru, jeśli jest taka potrzeba.

Przykładem złego kopiowania kodu w znaczącej większości przypadków jest powielanie kawałka kodu z innego obszaru tego samego projektu. W ten sposób zwiększa się niepotrzebnie ilość kodu. Większym problemem jest natomiast zaprogramowanie tego samego efektu wielokrotnie, przez co w przypadku potrzeby późniejszej modyfikacji łatwo jest doprowadzić do niekonsekwencji i w efekcie błędów aplikacji.

Najlepszym rozwiązaniem jest refaktoryzacja tego kodu w taki sposób, aby można go było wykorzystać w kilku miejscach (np. za pomocą wywołania jednej funkcji). Oczywiście od tej reguły bywają wyjątki i w przypadku problemów z oceną sytuacji najlepiej zapytać kolegę po fachu o niezależną opinię.

Bonus: Wypalenie zawodowe

Nawet najbardziej lubiane zajęcie, bez którego nie potrafisz wyobrazić sobie życia, w nadmiarze może stać się uciążliwe. Brak rozwoju, stawiania sobie wyzwań, odpoczynku oraz zachowania balansu między pracą (będącą często również i hobby) a życiem prywatnym, może skutkować w powolnym przyrostem niechęci do wykonywanych zadań jak i spadku wydajności. Nie inaczej jest z programowaniem. Niezależnie czy wciągnie Cię jakieś zagadnienie, czy może szef każe zostać po godzinach, kontroluj czas spędzany nad programowaniem, a także staraj się robić proporcjonalne przerwy od pracy przy komputerze. Twój organizm odpłaci Ci za to zdrowiem psychicznym, fizycznym oraz zapałem do dalszej pracy.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z