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?