Nie patrzmy na frontendowca jak na młodszego brata. Devdebata

– Niestety na frontend często patrzy się jak na młodszego brata – z przymrużeniem oka. Jest to zapewne narzut myślenia w kategoriach tego, że front to html i css, a frontendowcy to nie do końca “prawdziwi” programiści. W dzisiejszych czasach front to naprawdę rozbudowany stack i duże aplikacje, mierzymy się z innymi problemami niż backend, ale nie umniejsza to ich wagi – powiedział nam Dawid Wojda, CEO-Founder w Code8, Fullstack, który w tych kilku zdaniach ujął powód, dla którego podjęliśmy się zrealizowania tej devdebaty.

W poprzednim odcinku zapytaliśmy backendowców o to, jak mogliby jeszcze lepiej współpracować z frontendem. Dziś o to samo pytamy frontendowców. Kto podzielił się spostrzeżeniami?

Krzysztof Węgliński. Senior Frontend Developer w Nglogic. Javascript developer od prawie 10 lat. Największą przyjemność czerpie z refactoringu rzeczy, których nie da się naprawić. Od lat pracuje zdalnie i promuje tę formę pracy. Praktyki refactoringu przenosi również na życie codzienne, w wolnych chwilach oddając się renowacji mebli i samochodów.


Dawid Wojda. CEO-Founder w Code8, Fullstack. Specjalizuje się w JavaScripcie po stronie frontu i serwera. W pogoni za rozwiązaniem problemu potrafi zagalopować się aż do zagadnień niskopoziomowych, jest fanem wizualizacji a specjalizuje się w grafach i sztuce generatywnej, ciągle szuka i eksperymentuje. Mniej zawodowo: aquascaper, zwolennik aktywnego wypoczynku i gór. Zaprasza do śledzenia profilu na Twitterze.


Patryk Pawłowski. Senior Full Stack JavaScript Developer w Toptal oraz product designer w jednym. Od ponad 6 lat pracuje zdalnie – głównie dla firm i startupów z USA i Szwajcarii. W ostatnim czasie zajął się również szerzeniem pracy zdalnej. Ma doświadczenie w prowadzeniu własnego biznesu. W wolnym czasie lubi podróżować, pływać na kitesurfingu, a zimą uprawiać ski-touring.


Adam Pacanowski. Senior Frontend Developer w mTab. Pisał aplikacje dla biznesu w React, zanim większość programistów o nim słyszała. Napisał i obronił pracę magisterską projektem opartym tylko o technologie frontendowe. Wyznaje zasadę: „Done is better than perfect” (oczywiście z sensownie, dobrze ustawioną definition of done). Hobbysta.


1. Czy prowadzisz użytkownika za rękę zgodnie z tym, czego back-end wymaga w rozwiązaniu danego problemu? Czy wiesz jakich informacji back-end wymaga tu i teraz (także implicity)?

Krzysztof Węgliński: Zależy to od projektu. Często jak mamy do czynienia z dużą firmą (np. korporacją) “góra” ustala design. Przez to proces jego zmiany jest mocno utrudniony, a w takich warunkach ciężko podejmować decyzje przyjazne użytkownikowi. W startupach natomiast znacznie łatwiej (jeśli nie obowiązkowo) jest wprowadzić swoje rozwiązania. Wtedy szukam rozwiązań, które najlepiej konwertują, co przekłada się na dostępność – minimalna możliwa ilość zadań po stronie użytkownika, podział na kroki itp. Wiem, bo uważam, że muszę wiedzieć jakie są wymagania backendu, zwykle dzięki dokumentacji choć ta nie zawsze jest dostępna. Niestety było kilka projektów, gdzie nie było ani dokumentacji, ani informacji i trzeba było zapoznać się z kodem.

Dawid Wojda: Tylko w momencie, gdy w 100% zgadzam się z wymaganiami backendu. Bardzo często zdarza mi się „kłócić” z backendem, biznesem itp. o słuszność spornych funkcjonalności, pewnie dlatego, że do projektów podchodzę całościowo. Zdobywam wiedzę dziedzinową i staram się zastanawiać nad tym, co tak naprawdę chcemy użytkownikowi ułatwić. Reasumując każdy system ma ułatwić czy ustandaryzować przeprowadzenie jakiegoś procesu. Gdzieś tam zawsze będzie siedział człowiek, który będzie nas przeklinał za to, że np. pole „dodatkowe informacje” w formularzu jest wymagane, a nie opcjonalne. To my frontendowcy jesteśmy najbliżej klienta i musimy często weryfikować słuszność wymagań innych.

Patryk Pawłowski: Podobnie jak Dawid, często dyskutuję z biznesem, projektantami czy back-endowcami na temat proponowanych rozwiązań. Jako zespół mamy szersze spojrzenie na dany problem (np. ścieżkę użytkownika). Projekt jest żywym organizmem i powinien ewoluować. W końcu po to są nam te wszystkie zwinne metodyki, abyśmy mogli ulepszać nasz produkt po każdym sprincie. Nikt na początku nie ma 100% informacji i nie rozważy wszystkich możliwych scenariuszy. Dlatego po raz kolejny niesamowicie istotna jest współpraca i komunikacja w zespole, ale również z biznesem i użytkownikami.

Adam Pacanowski: Wszystko zależy od konkretnej funkcjonalności, którą mamy zaimplementować i źródła jej pochodzenia. Jednak często zdarza mi się rozmawiać z zainteresowanymi w firmie osobami (nie tylko osobami z backendu) na temat rozwiązania. Często jest to długa droga, a sami interesariusze nie są na pierwszy rzut oka widoczni. Robię to ponieważ według mnie bardzo ważny jest „feeling” aplikacji przez użytkownika tak, aby czuł się w niej dobrze, chciał z niej korzystać i chciał do niej wracać.

2. Jak rostrzygasz kwestie sporne na linii backend-frontend?

Krzysztof Węgliński: Przede wszystkim zaczynam od spotkania, najlepiej 2-4 osób. Ustalamy gdzie jest problem, z czego wynika i jakie są możliwe rozwiązania. Wybieramy rozwiązanie, które przyniesie najwięcej korzyści lub czasem to, które zajmie najmniej czasu (wciąż musi to mieć sens). Oczywiście zdarza się, że coś powinno dziać się na backendzie, ale są próby zepchnięcia tego na front (lub odwrotnie). Wtedy trzeba walczyć o rozwiązania zgodne ze sztuką, ale to już inna historia.

Dawid Wojda: To ciekawe pytanie, ciężko jednak odpowiedzieć na nie nie znając kontekstu sporu. O ile nie dałoby się załatwić tego przez maila to zorganizowałbym spotkanie. Czasem warto pokusić się o określenie ról, np. według macierzy RACI i potem podsumowanie spotkania tak, aby na koniec, na papierze (mailu/Jirze itp.) określić, co musi się stać, aby problem rozwiązać i osoby bezpośrednio odpowiedzialne za wdrożenie planu.

Adam Pacanowski: Najważniejsze jest porozumienie oraz wzajemne zrozumienie, ponieważ obie strony dążą (albo przynajmniej powinny) do tego samego, czyli działającego oprogramowania. W związku z tym najlepiej porozmawiać z zainteresowanymi osobami, wytłumaczyć, podyskutować, może nawet czasami w jakimś stopniu ustąpić, tak aby poruszyć sprawę do przodu.

3. Jaka Twoim zdaniem wiedza na temat frontendu mogłaby ułatwić pracę backendowcom?

Krzysztof Węgliński: Podstawy. Czym jest SPA, co próbujemy uzyskać, standardowy przepływ danych. Również, to już zależy od specyfiki projektu, jak te dane są potem przetwarzane. Np. data sety pod kątem wyświetlania danych.

Dawid Wojda: Przede wszystkim to, że front ma sporo na głowie. Aby nasze programy pozostawały responsywne musimy wyrobić się z obliczeniami w kilkanaście milisekund, dlatego czasem lepiej, aby niektóre rzeczy zostały zrobione po stronie serwera. Nie zawsze chodzi o to, aby backendowi zrobić na złość większą ilością pracy.

Poza tym wiedza na temat technologii gdzie nasze programy się stykają, czyli np. CORS, REST itp. oraz ogólne pojęcie o tym, co dzieje się na froncie. Warto poświęcić kilka godzin aby ktoś z frontu zrobił krótką prezentację na temat wewnętrznego stacku.

Adam Pacanowski: Podstawowa znajomość narzędzi developerskich wbudowanych w przeglądarkę, zwłaszcza zakładki „Sieć”. Dzięki temu backendowcy bez niczyjej pomocy są w stanie sprawdzić czy zapytanie zostało poprawnie zdefiniowane przez frontend, czy odpowiedź jest zgodna z ich oczekiwaniami lub dlaczego plansze ładowania są tak długo widoczne.

4. Jaki zestaw wiedzy dot. backendu jest niezbędny do pracy każdego frontendowca?

Krzysztof Węgliński: Tu znów przepływ danych i bardzo przydane zdają się być podstawy danego języka czy samego backendu. Bardzo często wygodniej jest mi zajrzeć do kodu backendowego i zrozumieć np. czego backend potrzebuje do danego requestu.

Dawid Wojda: Warto wiedzieć jak działają relacyjne bazy danych, jaka technologia/język jest używana po stronie backendu, ale tutaj tak jak przypadku frontu, wszystko będzie zależeć od stacku firmy w której pracujemy. Najlepiej gdyby przedstawiciele obu grup na bieżąco starali się komunikować, zaczynając od prezentacji dla nowych kolegów/koleżanek.

Adam Pacanowski: Myślę, że dużo zależy tutaj o tego, co i w jaki sposób jest używane po backendzie. Jednak zazwyczaj warto, aby frontendowcy w jakiś sposób umieli przeglądać, obsługiwać czy backupować i odtwarzać stosowaną warstwę persystencji (oczywiście zależnie od tego jak w danym projekcie jest to im potrzebne). Dodatkowo dobrze by było żeby wiedzieć jak przebieg cały proces budowania aplikacji, zarówno po stronie frontu, jak i backendu, tak aby w razie problemów szybciej go rozwiązać.

5. Dlaczego zarobki backendowców są z reguły wyższe niż zarobki frontendowców?

Krzysztof Węgliński: Hm, to zależy od projektu. Począwszy od braku zrozumienia na czym polega praca frontendowców, po bardziej skomplikowane rozwiązania, nad którymi backendowcy pracują. Są projekty, gdzie backendowcy nie pracują nad niczym poważniejszym niż standardowy zapis/odczyt danych z jakąś autoryzacją, a to frontend szaleje. Są jednak projekty, gdzie backend razem z data science budują skomplikowane struktury danych i na ich podstawie generują wyniki w milisekundy, a frontend buduje proste formularze do wprowadzania tych danych.

Dawid Wojda: Niestety na frontend często patrzy się jak na młodszego brata – z przymrużeniem oka. Jest to zapewne narzut myślenia w kategoriach tego, że front to html i css, a frontendowcy to nie do końca “prawdziwi” programiści. W dzisiejszych czasach front to naprawdę rozbudowany stack i duże aplikacje, mierzymy się z innymi problemami niż backend, ale nie umniejsza to ich wagi. Brzydki i wolny interfejs to katastrofa dla projektu. Każdy pracodawca, któremu zależy na wizerunku firmy i dobrym odbiorze produktu powinien dbać tak samo o warstwę prezentacji jak każdą inną, co za tym idzie o ludzi za nie odpowiedzialnych.

Adam Pacanowski: To co teraz nazywamy teraz frontendem rozpowszechniło się na szeroką skalę dopiero od paru lat i właściwie nie jest wcale kształcone np. na studiach informatycznych. Nie ma zatem na rynku odpowiedniej liczby frontendowców (tym bardziej w porównaniu do liczby backendowców). A dalej wydaje mi się, że zachodzi zwykła ekonomiczna zasada popytu i podaży.


Zdjęcie główne artykułu pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
Polecamy
Lepiej pracuje się w 100% zdalnym zespole? Devdebata