Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Poważne podziały w WebDevie

Poznaj podziały w WebDevie, które mogą mieć negatywny wpływ na zespoły i organizacje.
Poważne podziały w WebDevie

The Great Divide to esej Chrisa Coyiera, napisany w styczniu 2019 roku. Próbuje on wyjaśnić nowe zjawisko, które pojawiło się w społeczności front-endowej. A wygląda następująco: po jednej stronie mamy programistów, którzy bardzo dobrze posługują się JavaScriptem, a po drugiej programistów, którzy bardzo dobrze znają HTML-a, CSS-a, dostępność i projektowanie stron internetowych. Mimo iż obie grupy nazwą same siebie front-endowcami, to tak naprawdę nie mają takich samych zainteresowań czy umiejętności. Według Chrisa "nie mają o czym rozmawiać".

Istnieją jednak też inne podziały, które czają się w świecie oprogramowania poza front-endem. Niektóre z tych podziałów istnieją od dziesiątek lat, a inne od momentu, gdy uknuto termin "inżynieria oprogramowania", jakieś 50 lat temu. Poza tym istnieje jeden podział. Taki, który z perspektywy żadnego rozsądnego człowieka nie powinien istnieć.

Ten tekst będzie mówił o ważnych podziałach w web developmencie i o wpływie, które mogą mieć na zespoły, społeczności i organizacje. Istnieją starsze i mocniejsze podziały niż te, które widzisz obecnie w społeczności front-endowej


Front-end a back-end

Istnieje wielu webowych developerów, którzy potrafią tworzyć wspaniałe strony internetowe. Z jednej strony mamy ludzi wysoko wykwalifikowanych w zakresie działania przeglądarek - programistów front-endowych, a z drugiej - ludzi wykwalifikowanych w zakresie działania serwera - programistów back-endowych.

Idea front-endu w kontekście sieci pojawiła się jeszcze przed pojawieniem się jQuery. W tym czasie tworzyliśmy strony internetowe wewnątrz tabel i musieliśmy wymyślać kreatywne haki CSS-a do obsługi wszechmocnego IE 6. Choć wydaje się, że było to dawno temu, praktyka front-endu jest stosunkowo nowa, mając ledwo 20 lat na karku. Z drugiej strony back-end ma tyle lat, co pierwsze komputery.

Jeśli budujesz aplikacje back-endowe, uczysz się niezliczonych podstaw, niezbędnych do tworzenia oprogramowania, które inteligentni programiści odkryli już kilkadziesiąt lat temu. Praktyki te nie są zgłębiane przez programistów, którzy są bardziej zainteresowani technologiami front-endu. To działa w dwie strony. Jeśli jesteś przyzwyczajony do budowania aplikacji front-endowych, uczysz się podstaw działania przeglądarek, co nie zainteresuje back-endowców.

Back-endowych deweloperów nie obchodzi front-end. Front-endowych nie obchodzi back-end


Ten podział zainteresowań tworzy ogromną lukę wiedzy po obu stronach.

W przypadku społeczności IT taki podział uniemożliwia dzielenie się doświadczeniami i wiedzą. Utrudnia osiągnięcie znacznego potencjału w zakresie innowacji technologicznych.

Np. powiedzmy, że poszedłeś na meetup poświęcony back-endowym językom. Najprawdopodobniej spotkasz wyłącznie back-endowych deweloperów. “Kultura pogardy” wobec front-endowców to coś, co łatwo powstaje w takich warunkach. 

Wyobraźmy sobie, że na tym samym spotkaniu jest kilku młodych programistów, którzy dopiero rozpoczynają swoją karierę w branży oprogramowania. Jeśli usłyszą negatywne opinie i zniechęcą się do front-endu, będą również gardzić wszystkim, co z tym związane, w przyszłości. Ta separacja tworzy środowisko, które jest w pewien sposób ograniczone, gdyż nie wykorzysta do swojej pracy potencjalnie przydatnych elementów z programowania front-endowego lub samej wiedzy specjalistów tej przeciwległej odnogi.

Z perspektywy organizacji, to zachęca każdy zespół do duplikowania logiki zarówno we front-endzie jak i back-endzie.

Np. masz przełącznik stanu na backendzie: “PENDING” i “CANCELLED”. Biorąc pod uwagę, że programiści front-end pracują niezależnie od siebie, jest bardzo prawdopodobne, że skończysz z tą samą logiką w kodzie front-endu. Później, jeśli zechcesz utworzyć nowy stan, będziesz musiał zmienić zarówno front-end, jak i back-end, zamiast zmieniać wszystko tylko w jednym miejscu.

Jeśli jesteś programistą front-end, zapewne tworzysz systemy z ciężkim kodem JavaScript po stronie klienta i lekkim kodem po stronie serwera. Jeśli jesteś backendowcem, tworzysz systemy z ciężkim kodem po stronie serwera i lekkim kodem po stronie klienta.

Poruszałem już ten temat w artykule, który pokazuje, jak separacja back-endu i front-endu może doprowadzić do pisania bezużytecznego kodu. Więcej przykładów możesz zobaczyć tutaj: Sepracja front-endu i irracjonalna miłość do zakręconych nawiasów.

Rozdzielenie front-endu i back-endu tworzy zachęty dla programistów do pracy w izolacji, powielania logiki i rozwijania wszystkiego jedynie w przeglądarce lub jedynie na serwerze


Operacje infrastrukturalne a rozwoju produktów

Z jednej strony masz ludzi wysoko wykwalifikowanych w zakresie działania protokołów sieciowych i sprzętu, a z drugiej - w zakresie architektury oprogramowania i projektowania.

Jeśli masz większe zainteresowanie działaniem infrastruktury, masz tendencję do pozbawiania przywileju uczenia się zasad projektowania oprogramowania związanych z szybkim i zrównoważonym rozwojem produktu. Zwykle koncentrujesz się na komputerach i wyzwaniach technologicznych związanych z ich działaniem: wysoka dostępność.

Skupianie się na tym, aby komputery działały, pomaga w nauce, w projektowaniu niezawodnego oprogramowania i stawia na obserwowalność sprzętu. Nie pomaga to jednak w nauce projektowania systemów, które mogą zapewnić dostępność z perspektywy użytkownika. Np. nie ma sensu, aby serwer był gotowy do pracy, jeśli użytkownik musi oglądać obracające się kółko przez godzinę, by uzyskać to, czego chce. Z punktu widzenia użytkownika to jest awaria.

Twoją codzienną rutyną kodowania jako programisty Infrastructure Operations może być pisanie małych, samodzielnych skryptów Bash lub kodu infrastruktury, takiego jak Terraform. Dlatego uczenie się technik zautomatyzowanego testowania, takich jak TDD, nie ma większego sensu; nie ma też sensu uczenie się jak zmienić swój projekt, aby był bardziej testowalny.

Jeśli jesteś bardziej zainteresowany rozwojem produktu, to może brakować Ci wiedzy o podstawowych zasadach fizyki. Łatwo wpadasz w 8 błędnych przekonań o obliczeniach rozproszonych. Masz tendencję do optymalizacji pod kątem świetnych zasad projektowania i programowania, które mogą zwiększyć łatwość utrzymania i zmniejszyć koszty programowania (SOLID, XP, Connascence, Cohesion). Jednakże tracisz również możliwość poznania wyzwań związanych z fizycznymi granicami, w których komputery działają w realnym świecie. Jak to mówią: "Chmura nie istnieje, to tylko czyjś komputer", a komputer znajduje się gdzieś w świecie rzeczywistym.

Podział na infrastrukturę i rozwój produktu stwarza zachęty dla programistów, aby nie starali się zrozumieć fizycznych wyzwań związanych ze sprzętem, a dla działu operacji, by nie rozumieli ekonomicznych kosztów oprogramowania.


User Experience a Front-end Development

Z jednej strony mamy ludzi o dużych umiejętnościach w zakresie tworzenia user experience i wizualnego projektowania systemu, a z drugiej ludzi o dużych umiejętnościach w zakresie używania HTML-a, CSS-a i JavaScriptu w celu tworzenia “żywej” strony internetowej dla produkcji.

Z punktu widzenia projektanta, buduje on przepływ użytkowników w oparciu o informacje zwrotne od klientów wraz z artefaktami wizualnymi w celu dopasowania ich do brandingu firmy. Jednakże, kiedy przekazują to programistom front-endowym, programiści narzekają, że końcowy rezultat nie pasuje do ich wewnętrznej biblioteki komponentów. Skarżą się również na to, że elementy zaangażowane w zamierzony przepływ od projektanta są trudne i kosztowne w produkcji. Rezultat znacznie różni się od tego, co przewidział projektant.

Z punktu widzenia dewelopera, otrzymuję on piękny przepływ i design. Jednakże projekt wykazuje zerowe zrozumienie tego, jakie koszta związane są z jego rozwojem. 

Niektóre komponenty nadają się do wielokrotnego użytku, ale projekt ich nie wykorzystuje. Zespół może zmienić niektóre części interfejsu użytkownika, ale innych nie może nawet dotknąć. Np. projektant może stworzyć prezentację onboardingową, która obejmuje wszystkie komponenty strony. Jednak projektant nie wie, że zespół kontroluje tylko jeden iframe wewnątrz głównej strony internetowej. Jest technicznie i politycznie niemożliwe, aby mieć na stronie onboarding, który prezentuje wszystkie jej komponenty bez przepisywania całego systemu.

Podział między UX i front-endem stwarza sytuację, w której deweloper narzeka na projektanta, a projektant na dewelopera


Istnieje wiele powodów, dla których powstały te podziały. Główną z nich jest to, że firmy i społeczności programistyczne opierają swoje role na technologii:

  • "front-end JavaScript developer."
  • "front-end HTML/CSS Developer."
  • "DevOps Engineer."
  • "back-end Developer."
  • "UX Designer."


Zamiast opierać swoje role na umiejętnościach i możliwościach biznesowych:

  • "Online Sales."
  • "Customer Recovery Department."
  • "Automated Billing."
  • "Employee Experience."
  • "Online Marketing."


Każdy uważa, że koszt, jaki jedna osoba musi ponieść, aby nauczyć się najważniejszych podstaw niezbędnych do rozwoju oprogramowania, jest zbyt wysoki. Z tego powodu rynek stwarza zachęty dla ludzi, aby szli na skróty, zdobywając konkretne specjalizacje w celu szybkiego znalezienia pracy i rozpoczęcia kariery. 

Najszybszym sposobem wejścia na rynek pracy jest zrobienie specjalizacji 


Podsumowując, istnieje wiele technologii dzielących rozwój oprogramowania, takich jak podział pomiędzy JavaScriptem i HTML-em w web dewelopmencie. Inne podziały to:

  • "back-end" i "front-end".
  • "Operacje" i "Rozwój produktu".
  • "UX Design" i "Front-end Development".


Dla nas, jako programistów, najważniejsze jest zrozumienie podstaw rozwoju oprogramowania, a nie koncentrowanie się wyłącznie na jednym stosie technologicznym. Pozwala to zobaczyć wszystkie granice tego, co jest możliwe, i co nie jest możliwe; zrozumieć kompromisy jednego podejścia technicznego nad drugim, w praktycznym kontekście biznesowym.

Kod, który piszesz w celu rozwiązania jakiegoś problemu, niesie ze sobą też inny cel. Celem jest wytworzenie wartości, a nie tylko napisanie kodu. To właśnie jest programowanie.

Dla firmy najważniejsze jest stworzenie kultury współpracy. Jeżeli praca, jaką mamy wykonać wymaga zaangażowania wielu ról, spróbujmy te role zbliżyć do siebie jak najbardziej - zbierzmy je razem w jednym pomieszczeniu, w jednym czasie, w jednym komputerze. Twórzmy kulturę wspólnego przeglądu kodu, programowania parowego i grupowego.

Jako programiści, musimy uczyć się podstaw, a jako firma - współpracy.

Poza tym wszystkim, co opisałem, istnieje jeszcze jeden podział, który ma miejsce w każdej dużej organizacji; podział, który nigdy nie powinien powstać - na tych, którzy tworzą oprogramowanie i tych, którzy go używają. To podział na deweloperów i klientów. Ale to już temat na inny tekst.


Oryginał tekstu w języku angielskim przeczytasz tutaj.

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej