Rzeczy są stworzone często parami.
Jako ludzie lubimy upraszczać sobie pewne rzeczy, np. zwierzaki: najbardziej popularna para to psy i koty.
Możemy mówić o czymś, co jest wewnętrzne i zewnętrzne – to podstawowy sposób klasyfikacji.
Obszar programowania również składa się z warstw i nie zdziwię Cię, że tutaj nie ma niespodzianek.
No może jest jedna niespodzianka – nie wszystko ma dobre tłumaczenie na język polski i często lepiej się kojarzy oryginalne nazwy.
Warstwy w programowaniu
Oto wspomniane warstwy:
- Frontend – warstwa zewnętrzna (wizualna, kliencka), można to nazwać: czołówka
- Backend – warstwa wewnętrzna (zaplecza, serwerowa, funkcjonalna), można to nazwać: silnik
To co widzimy jako użytkownicy, to warstwa wizualna.
Musi mieć fizyczną i namacalną postać. W końcu nie będziemy się domyślać, że gdzieś tam w interfejsie jest jakaś ikonka, która coś robi. W danym momencie albo ona jest (widoczna), albo jej nie ma (ukryta).
Sfera wizualna to nasz interfejs do komunikacji i używania aplikacji.
Warstwa czołówki (frontend)
Część wizualna zaprasza do siebie pojęcia:
- UI (ang. User Interface) – pojęcie obejmujące układ graficzny, styl ikon, tekstu. Każdą aplikację możnaby opisać w pewien sposób. Przykładowo: u góry jest tytuł (albo na pozycji X=10,Y=20 jest tytuł aplikacji) i UI właśnie obejmuje to, jak układ graficzny jest zbudowany.
Może obejmować nawet sposób animacji przycisku po kliknięciu.
Sens, czy dana ikona powinna być w danym miejscu lub czy jest użyteczna – to już inny obszar, a mianowicie: - UX (ang. User Experience) – pojęcie obejmuje już mniej oczywistą kwestię z punktu widzenia fizyczności – czyli nie tyle, gdzie i jak wygląda dana ikonka, ale czy użytkownik ma szansę ją łatwo zlokalizować, jest w odpowiednim miejscu (ikonka, a nie użytkownik) i czy spełnia one swoje założenie
Z tego wykazu już możesz dostrzec, że o ile UI bardzo mocno dotyczy Frontendu to UX ma powiązanie i z Frontendem i z Backendem (część rzeczy można zrealizować w ograniczony sposób, co wpływa na odbiór funkcji przez użytkownika).
Patrząc niejako na Zasadę Pareto i aplikując ją tutaj, to: UX to 80% Frontendu i 20% Backendu. Odpowiednia proporcja i koncentracja na tym, aby oprogramowanie było użyteczne i ściśle współgrało z konceptem warstwy wizualnej sprawia, że program jest dla nas łatwy w obsłudze i funkcjonalny.
Ktoś powidziałby, fajnie, omówiłeś pojęcia frontendowe, ale co z backendem? Czy i tutaj jest jakiś jasny podział?
Warstwa silnika (backend)
Nie ma tutaj tak formalnego i mocno znanego podziału, jednak skrystalizowały się takie pojęcia, jak:
- BX (ang. Backend Experience) – jak użytkownicy końcowi odbierają działanie aplikacji. Bada się tutaj wydajność, niezawodność, bezpieczeństwo i skalowalność (możliwość użycia dla większej porcji danych, większej ilości klientów, większej ilości problemów do rozwiązania)
- DX (ang. Developer Experience) – jak programiści i osoby wdrażające aplikację (np. integratorzy) odbierają działanie procesu wytwarzania i rozwoju oprogramowania. W tym przypadku istotne są aspekty, takie jak: szybkość dostarczania nowych funkcji, łatwość diagnostyki problemów i detekcji błędów. Ważna jest też dostępność dobrej dokumentacji, efektywne realizacje testowania, krótki czas dostarczania/publikacji oprogramowania.
Z punktu widzenia klienta, DX może być nieistotny, jednak wyobraź sobie sytuację w której programista ma do wprowadzenia małą, ale pilną poprawkę, która ma być przestestowana i opublikowana pod koniec dnia.
Przychodzi do pracy i tego dnia automatyczna aktualizacja środowiska programistycznego wprowadziła zbyt duże zmiany. Środowisko nie pozwala na poprawne przygotowanie instalatorów. Trzeba coś zmienić w kodzie.
Rozpoczyna się walka z czasem, tj. ze środowiskiem, umysł programisty już przygotowuje niecenzuralne słowa pod kątem osób. Tych, którzy zdecydowali się opublikować tak niekompatybilną aktualizację lub pod kierunkiem właścicieli firmy, że wprowadzili takie procedury aktualizacji.
Gdy firma, w której rozwija się kod nie dopuszcza automatycznych aktualizacji bez przetestowania środowiska – mamy do czynienia z mocno przewidywalną sytuacją.
Wtedy lepiej się panuje się nad DX, czego efektem jest większa szansa na wywiązanie się z terminu publikacji poprawki. Czyli jest w stanie dostarczyć coś z lepszym UX.
Jakie to ma znaczenie?
Tutaj odpowiedz sobie na pytanie – czym jest dla Ciebie programowanie.
Od tej odpowiedzi zależy obszar, nad którym będziesz pracował.
Czy docelowo chcesz pracować na etacie, czy też tworzyć i sprzedawać własne produkty?
Każdy z obszarów ma inne wyzwania i w zależności od obszaru będziesz inaczej się koncentrował i patrzył na dany obszar.
Przy pracy na etacie, możesz wybrać, czy jesteś osobą od frontendu, backendu czy może jedno i drugie (fullstack). Możesz też być dev-opsem, czyli koncentrować się na procesie ciągłości wytwarzania oprogramowania, automatyzacji dostarczania i weryfikacji oprogramowania. W zależności od firmy możesz mieć mniejszy lub szerszy wachlarz obowiązków.
Zdecydowałeś się projektować i wydawać swoje własne produkty?
Gdy jeszcze nie masz osób, które mogłyby Cię wesprzeć w programowaniu, będziesz musiał zadbać, aby obsłużyć wszystkie 4 sekcje (UI, UX, DX, BX). Niechybnie będziesz rozwijał się w kierunku fullstack.
Ważne jest to, że nie musisz od razu poznawać wszystkiego.
Jednak jest bardzo potrzebne, aby być otwartym na naukę nowych rzeczy (i oczywiście jej wdrażanie).
W jakich obszarach Ty czujesz się najlepiej?