W poprzednim wpisie Jak zostać programistą? Rok 2023 opisałem krótko jak wygląda początek kariery w IT.
Dzisiaj chciałbym przedstawić, jak wygląda życie i proces nauki programisty aplikacji webowych, czyli dostępnych przez przeglądarkę internetową, na podstawie własnego doświadczenia.
UWAGA
Poniższy tekst jest skierowany głównie dla osób, które nigdy nie miały styczności z programowaniem. Pewne opisy zostały mocno uproszczone, aby osoby nietechniczne mogły w sposób przystępny zaznajomić się z tematem lub problematyką.
Na początek musimy rozgraniczyć dwie główne dziedziny:
Frontend i Backend
Czym jest Frontend?
Z angielskiego „front” znaczy „przód”. Osoba zajmująca się frontendem pracuje nad tym, co jest na przodzie aplikacji, czyli interfejsem graficznym.
Każdy tekst, przycisk, obrazek musi zostać zaprogramowany tak, aby poprawnie się wyświetlał i spełniał swoją funkcję np. po kliknięciu przycisku, dane z formularza muszą zostać wysłane na serwer.
Zanim jednak znajdzie się on na ekranie, osoba odpowiedzialna za frontend (zwana frontendowcem) musi dostać specyfikację od osoby odpowiedzialnej za wygląd. Nie będę tutaj wchodził w szczegóły tego procesu.
Specyfikacja mówi, że przycisk z napisem „wyślij” musi znaleźć się pod polem tekstowym. Więc to musimy zrobić.
Konstrukcja strony
W przypadku aplikacji webowych główny szkielet tworzony jest za pomocą HTML. Za pomocą tego języka możne zdefiniować strukturę dla naszych elementów strony / aplikacji. Definiujemy przyciski, pola tekstowe formularzy, linki, tekst itd.
Kolorki, rozmiary, rozmieszczenie
Ok, mamy szkielet naszej aplikacji. Teraz czas rozmieścić te elementy na ekranie. Służy do tego CSS.
Żeby uprościć, opowiem, jak najczęściej rozmieszcza się komponenty.
Najczęstszym pozycjonowaniem, jest pozycjonowanie relatywne. Oznacza to tyle, że tworząc nasz szkielet pozycjonujemy elementy względem poprzedniego. Np. przycisk pod tekstem ma być 20 pikseli poniżej tego tekstu. Obrazek ma się znajdować w odległości 10 pikseli po lewej od tekstu.
Elementy rozmieszczone, czas na kolorowanie.
Za pomocą CSS definiujemy, jaki kolor ma mieć przycisk. Czy rogi są proste, czy zaokrąglone. Czy tekst ma mieć rozmiar 14 czy 20. Oczywiście tych opcji jest dużo więcej, ale nie będziemy tutaj wszystkich rozpisywać 🙂
Wdaje się proste? Cóż, na razie tak.
Kolejny schodek. Różne przeglądarki, różne urządzenia.
Życie nie jest usłane różami. Każda przeglądarka — Chrome, Firefox, Safari, Edge — inaczej interpretuje różne wartości. Może się okazać, że jedna umożliwi nam zaokrąglenie rogów przycisku a druga nie.
Co możemy wtedy zrobić? Cóż… trzeba kombinować, ponieważ w wymaganiach jest, że przyciski mają mieć zaokrąglone rogi.
Jak to rozwiązać? Jeśli przycisk ma stałą szerokość, możemy przygotować obrazek z zaokrąglonymi przyciskami i tak przygotowany obrazek ustawić jako tło naszego elementu z przyciskiem.
Dobre rozwiązanie? To zależy.
A co jeśli tekst będzie dłuższy? Albo trzeba będzie zmienić kolor? No właśnie… tak jak pisałem w poprzednim wpisie, musisz mieć „Zdolność do podejmowania decyzji„. Musisz wybrać, co jest mniejszym złem.
Dobra, elementy ułożone, pokolorowane. Chciałbym teraz, aby przyciski na komputerze wyświetlały się w jednym rzędzie, natomiast na telefonie jeden pod drugim.
CO?!
Przechodzimy do kolejnego działu, czyli:
Responsive design
Skoro mamy już zrobiony układ dla komputera, to teraz trzeba dostosować stronę / aplikację do telefonu. Przecież ekran komputera jest szeroki i krótki, natomiast telefonu wąski i długi.
Otrzymujemy kolejną makietę od grafika, jak ma wyglądać aplikacja na telefonie. Okazuje się, że tekst musi się inaczej układać, przycisk mają mieć inny układ, a na telefonie ma się ten komunikat wyświetlić, a na komputerze nie.
Wspominałem, że po drodze jeszcze tablet?
Jak widzisz, musimy zrobić 3 widoki aplikacji, w zależności od urządzenia.
Przecież można zrobić 3 niezależne aplikacje.
Oczywiści, można. Trzeba jednak pamiętać, aby te 3 niezależne aplikacje utrzymać. Jeśli trzeba będzie zmienić tekst, trzeba to zrobić w 3 aplikacjach, czyli 3 razy więcej czasu na to poświęcić. Trzy razy więcej czasu oznacza 3 razy więcej pieniędzy, a to oznacza 3 razy wolniejszy rozwój aplikacji.
Nikt (rozsądny) na to nie pozwoli.
Dlatego proces tworzenia takiej aplikacji trwa. Trzeba zaplanować wygląd dla komputera, telefonu i tabletu. Wiele elementów jest wspólnych, ale wiele rzeczy się różni, żeby nam/wam użytkownikom lepiej i wygodniej się korzystało.
Interakcja
Mamy naszą makietę. Wygląda ślicznie na każdym z urządzeń — komputer, telefon, tablet.
Teraz trzeba zaprogramować „zdarzenia”. Jak klikniemy przycisk „A” to musi się zdarzyć to, co chcemy, aby zadziało się po naciśnięciu przycisku „A”. Jak klikniemy przycisk „B” to musi się zdarzyć to, co chcemy, aby zadziało się po naciśnięciu przycisku „B”. Jak wpiszemy niepoprawny tekst w polu liczbowym, musimy wyświetlić komunikat, że musisz wpisać liczbę, a nie tekst.
JavaScript
Do interakcji służy JavaScript. Za pomocą JavaScript (w skrócie JS) możemy określić, co ma się wydarzyć po kliknięciu danego przycisku, co się ma wydarzyć, kiedy użytkownik wpisze niepoprawny tekst w pole tekstowe i opuści to pole.
Ilość interakcji jest właściwie nieograniczona. To od specyfikacji projektu zależy, jak aplikacja ma się zachowywać.
Wróćmy do przykładu z polem tekstowym. Specyfikacja może opisać, że błąd walidacji (niepoprawnych danych) ma się wyświetlić w jednym z dwóch przypadków:
- kiedy użytkownik opuści pole
- kiedy użytkownik wpisuje wartość w pole
Decyzja zależy od klienta. Jak widzicie, rezultat jest ten sam, wyświetlenie informacji o błędzie, ale dwa różne przypadki uruchomienia.
A pamiętacie, że trzeba to jeszcze umieścić na rusztowaniu i pokolorować? 😏
Ale tego dużo!
To dopiero początek. Kolejne schody zaczynają się, kiedy musimy wymieniać informację między tymi komponentami. Np. po kliknięciu wyślij na formularzu, okaże się, że wymagane pole jest puste.
Musi zajść jakaś interakcja. Np. przescrollować ekran do tego miejsca błędu, podświetlić pole na czerwono, wyświetlić komunikat „Pole jest wymagane” i uniemożliwić wysłanie formularza.
Przypominam, że opowiadam tutaj tylko i wyłącznie o polu i przycisku w formularzu.
Wyobraź sobie bardzo rozbudowany formularz, np. podczas zgłaszania swoich danych w urzędzie lub ubezpieczalni.
Każdy element trzeba oprogramować. Każdy element trzeba umieścić na rusztowaniu. Każdy element trzeba pokolorować i umieścić na ekranie. Każdy element musi mieć zdefiniowane zachowanie.
Ułatwmy sobie życie
Jeśli wystarczyło Ci siły, aby dotrwać do tego miejsca, to mam dla Ciebie dobrą wiadomość. Są narzędzia, które ułatwiają pracę. Są to pojedyncze biblioteki, a połączone razem w jedno bardziej złożone narzędzie nazywane frameworkami.
Ułatwiają one pracę podczas kolorowania dostarczając np. gotowy zestaw przycisków na stronę. Musimy je tylko wykorzystać. Jak zostały zaimplementowane (zaprogramowane) nie musimy do końca wiedzieć.
Wiesz jak jeździć samochodem, ale nie koniecznie musisz wiedzieć jak jest zbudowany 😄
Podobnie z interakcją. Też zostały stworzone narzędzia, gotowe do używania. Jednak muszę Cię zmartwić.
Nie ma jednego, najlepszego narzędzia
Niestety, jak w życiu, stajemy po raz kolejny przed dokonaniem wyboru. Wyboru o tyle trudnego, że na początku życia naszej aplikacji, który zaważy na decyzjach w przyszłości. Możliwościach, a także ograniczeniach.
Przykładowe rozwiązania do CSS (możesz kliknąć każdy z nich, aby zobaczyć co oferują i czym się różnią):
Przykładowe rozwiązania do JS:
Jak widzisz, rozwiązań jest bardzo dużo. Każdy z nich rozwiązuje, często ten sam, problem w inny sposób. Inaczej działa, inaczej się zachowuje, inną ma wydajność. Pewne rozwiązania są bardziej przyjazne dla użytkownika, a pewne bardziej przyjazne dla dewelopera.
Dlaczego stosuje się takie rozwiązania?
Proces pisania aplikacji jest trudny i bardzo złożony. Do stworzenia czegoś bardziej skomplikowanego wymagany jest zespół. Dzięki zastosowaniu jednolitego rozwiązania każdy z członków zespołu łatwiej odnajdzie się w obcym kodzie, napisanym przez inną osobę.
Koniec?
Na dzisiaj tak. Pokazałem Ci bardzo ogólny zarys, jak wygląda praca frontend developera. Jak widzisz nie jest to takie proste i nie jest to tylko klikanie w kąkutor (kolokwialnie mówimy tak na komputer 😉).
Na sam koniec zostawiam Ci bezpośredni link do roadmapy frontendowca: https://roadmap.sh/frontend/
Jeśli chcesz kontynuować przygodę to zapraszam do drugiej części, czyli backend developer.