Jak zdefiniować Frontend? Czy jest to jedynie układanie elementów na stronie lub w aplikacji i dbanie o jej wygląd? Może to praca nad poprawą doświadczenia użytkownika i optymalizacja, a może zbiór funkcjonalności i logik, pozwalających użytkownikowi na skomplikowane operacje?
W większości przypadków Twoją odpowiedzią będzie “Wszystko powyższe”. Dziś chcę pokazać jak wyglądała moja ścieżka we Frontendzie – ścieżka, która zaczęła się od prostego, lecz ważnego “układania elementów”.
Zanim zostaniesz Juniorem
Bycie Junior Frontend developerem nie jest proste. Znalezienie pierwszej pracy może być niemałym wyzwaniem, pełnym wątpliwości w siebie i w podjętą ścieżkę kariery zawodowej. W dodatku dziś nawet od Juniora oczekuje się chociaż podstaw frameworka lub bibliotek JS, co nie zawsze możemy zaoferować.
Jednak tak długo, jak będziesz poszerzać swoją wiedzę i urozmaicać portfolio nie ma się czego obawiać, ponieważ są to małe kroki, które pozwolą Ci wyjść przed szereg kandydatów i tym samym dać się zauważyć na rynku pracy. Podobnie było w moim przypadku: choć umiałem co najwyżej Vanilla JS wyróżniałem się innymi umiejętnościami, dzięki czemu zostałem UI developerem, nieświadomie podążając w kierunku frameworka Angular.
Kim jest UI developer?
UI developer to określenie Frontend developera, który tworzy jedynie User Interface. Taka osoba odpowiedzialna jest za wygląd strony bądź aplikacji, jej responsywność i ogólny odbiór przez użytkownika. Logika (w postaci Javascriptu lub Typescriptu) pozostawiona jest w większości Angular developerom.
Taki UI dev głównie korzysta z CSS, HTML i bibliotek UI odpowiednich dla danego frameworka lub biblioteki. I choć wydaje się to błahe i proste, może dla niektórych stanowić wyzwanie, ponieważ praca nie kończy się na pisaniu stylów i tagów. Istotne są również optymalizacja, wyczucie stylu, kolorów oraz znajomość popularnych rozwiązań UI/UX i wiedza jakich rozwiązań unikać, nie zapominając także o accessibility i SEO.
W Angularze UI developer powinien znać biblioteki UI do niego przeznaczone, np. Angular Material czy PrimeNG, być zaznajomionym z dostępnymi w nich komponentami i dokładnie wiedzieć kiedy i jak ich odpowiednio używać. Z takich najmniejszych bloków będzie on tworzył większe UI komponenty, a nawet feature’y, gdzie najczęściej plik *.ts pozostanie nietknięty.
Od zera do Angular developera
Pomimo tego, że miałem doświadczenie w Javascripcie, większość mojej pracy polegała na tworzeniu UI w aplikacjach webowych i mobilnych opartych o Angulara. Oznaczało to potrzebę nauki podstaw Angulara, a także poznania Angular Material i zrozumienia reguł stojących za Material Design.
To z kolei – mimo że celowo nie uczyłem się Angulara – stopniowo zwiększało moją wiedzę na jego temat. Błyskawicznie zacząłem poznawać fundamentalne mechanizmy tego frameworka: komponenty, moduły, two-way binding, dependency injection, a także te mniej fundamentalne, jak formularze, dyrektywy, RxJS itd.
Dzięki temu, że pracowałem z developerami z House of Angular, miałem stały dostęp do kodu wysokiej jakości, pełnego dobrych praktyk. W wyniku pracy w Angularowych projektach i stosowaniu bardzo podstawowych elementów tego frameworka mimowolnie się go uczyłem. Taka nauka jest bardzo przyjemna, bo przebiega powoli i stopniowo, ale nie jest zbyt efektywna.
Parę słów o tworzeniu UI
Pierwszym i najważniejszym krokiem w tworzeniu UI jest layout. Tworzenie takiego layoutu musi być przemyślane, aby aplikacja wyglądała poprawnie nawet przy większej liczbie feature’ów i danych. Layout musi być także elastyczny, aby w przypadku zmian nie był konieczny duży refactor. Przemyślany powinien być także kod, aby był przede wszystkim łatwy w utrzymaniu.
Na szczęście zadaniem UI developera nie jest przygotowanie designu, a jedynie zaimplementowanie go. Zanim aplikacja zacznie być pisana tworzona jest jej makieta lub design, za co odpowiada UI/UX Designer, a także klient. Dla UI deva makiety, design oraz specyfikacja to podstawa pracy.
Oczywiście już sam layout aplikacji może wymagać używania komponentów z bibliotek UI: regularnie pojawiają się makiety z sidebarem, a to oznacza – w mojej pracy – mat-sidenav jako fundament całej aplikacji. Jeżeli design przewiduje navbar w górnej części aplikacji, potrzebny będzie mat-toolbar, zaś wszelkie menu będą implementowane z użyciem mat-menu.
Komponenty w Angular Material zostały znakomicie dobrane: zdecydowana większość z nich jest często używana, a sposób w jaki są zaimplementowane pozwala na łatwe użycie i równie łatwą modyfikację.
Początki
Pierwszy projekt jako UI developer zacząłem od stylowania odseparowanych od aplikacji komponentów, w tymczasowym module, z którego Angular dev mógł później ten komponent przenieść w odpowiednie miejsce i kontynuować pracę nad nim, zapewniając odpowiedni routing, wstrzykując właściwe serwisy i generalnie połączyć go z resztą aplikacji. W skrócie: jego pracą było ożywienie “zmockowanego” komponentu, bądź czasem całego feature’a.
Takie podejście jest bardzo “czyste” – odseparowuje pracę moją i innej osoby, dzięki czemu zazwyczaj nie zostawia miejsca na błąd, ponieważ działam na komponencie, który sam tworzę. Niestety jest ono również skrajnie niewydajne: aby Angular developer mógł zabrać się za tworzenie logiki komponentu, najpierw ja muszę go w pełni ukończyć. Często też taka logika może powodować zmiany w komponencie, takie jak ukrycie jego istniejącego fragmentu bądź pokazanie nowego, co może wymagać poprawek z mojej strony.
Dlatego też, podejście to szybko się zmieniło i zacząłem działać na komponentach, które już istniały i były częścią aplikacji. W odróżnieniu od innych rozwiązań frontendowych, Angular ma tutaj przewagę: na komponent składa się kilka plików. Podczas gdy drugi developer działa nad logiką komponentu w pliku *.ts, ja mogę do woli działać w pliku *.scss. Jedynym punktem styku – podatnym na konflikty – jest plik *.html, gdzie rozwiązanie ich jest stosunkowo proste, ponieważ moja praca dotyczy tagów, ich atrybutów i klas, z kolei inny developer zajmuje się głównie Angularowymi “wstawkami”.
Zmiana podejścia była sukcesem, dzięki któremu przez długi czas tworzyłem UI w wielu dużych i średnich projektach. Z czasem to ja zacząłem tworzyć komponenty w odpowiednich miejscach, podpinać odpowiedni route, dodawać podstawową logikę. Zanim się obejrzałem, dostosowywałem spore feature’y bądź je rozszerzałem, tworzyłem Nx’owe biblioteki i generowałem NgRx’owe store’y.
To nie wszystko
Jednak jeżeli Twoim celem jest zostać Angular developerem – to nie wystarczy. Wcześniej wspomniane przykłady to tylko pojedyncze, nieregularne zadania, często opierające się na istniejącym już kodzie. Chcąc ewoluować w Angular developera konieczna jest samodzielna nauka: tutoriale, dokumentacja, artykuły, newslettery i przede wszystkim: praktyka.
Nic nie nauczy nas tak, jak własne projekty; jak tworzenie czegoś od zera; jak rozwiązywanie problemów, których nigdy wcześniej nie napotkaliśmy. Własne projekty warto zacząć od prostych i małych: ToDo App, Pomodoro, Kalkulator. Do napotkania niecodziennych problemów (bo podczas nauki chcemy ich znaleźć jak najwięcej) dobrym pomysłem jest też gra, na przykład Memory.
Z czasem projekty takie jak system logowania czasu czy aplikacja do zarządzania klientami nie będą już stanowić wielkiego wyzwania. Na koniec bardzo polecam tworzenie własnych, uproszczonych implementacji projektów z pracy – w razie trudności mamy możliwość podejrzeć jak problem został rozwiązany w “oryginale”. Bez względu na to, w jakiej technologii chcemy pisać aby się jej nauczyć należy tworzyć.
Co dalej?
Często jednak taka nauka może trwać i trwać. W moim przypadku jednak, dzięki temu, że pracowałem w miejscu stawiającym na rozwój i pełnym pomocnych developerów kulminacją nauki była weryfikacja mojej wiedzy przez doświadczonego Angular developera. Poczucie “rozmowy kwalifikacyjnej”, a także określony, sztywny termin bardzo mobilizują człowieka.
Następny w kolejce był pierwszy komercyjny projekt, w którym moja rola nie ograniczała się już jedynie do przygotowania UI. Taki projekt bardzo wyraźnie pokazuje ile jeszcze pozostaje do nauki, wszak między “domowym”, a komercyjnym projektem jest ogromna przepaść. Jednak ta przepaść jednocześnie pozwala nam odkrywać kolejne narzędzia, które sprawią, że zechcemy przepisać na nowo nasze własne projekty, w końcu o ile prościej jest napisać ToDo App mając do dyspozycji NgRx?
Niezależnie od tego, jaką ścieżkę obierzemy, w Angularze nie ma drogi na skróty, są jedynie drogi mniej lub bardziej strome. Ścieżkę, którą dane było mi obrać uważam za fantastyczną. Dla wielu próg wejścia Angulara jest zbyt wysoki, jednak dla mnie – dzięki pracy jako UI developer – ten próg był znacznie zaniżony. Bardzo ważnym czynnikiem jest również miejsce pracy, które ma oczekiwania i aktywnie pomaga je spełnić. Nie wyobrażam sobie lepszego miejsca do rozpoczęcia nauki kariery niż House of Angular.
Dodaj komentarz