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ń.

praca w it

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.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
warsztaty spark academy
Spark Academy 2020. Warsztaty dla programistów Ruby on Rails i JavaScript