Backend czy fullstack, jak zostać prawdziwym specjalistą ?

Takie coś może działać przy małych i średnich monolitach, w software housach czy wewnętrznych narzędziach firmowych. Jak produkt jest duży, a samych aplikacji frontendowych jest kilkadziesiąt, to nie ma miejsca na fullstacków.

Duzy produkt oparty o mikroserwisy niekoniecznie oznacza kilkadziesiat aplikacji UI. Ponadto UI mozna rozsadnie podzielic na odpowiedzialnosci, tak ze czesc mikroserwisow ma odpowiadajacy im "lekki" front- komponenty, ktore nastepnie sa skladane w calosc w dedykowanym serwisie (aplikacji UI).

Tak jak patrzę po odpowiedziach, to jednak przeważa to, że bardzo ciężko być tylko i wyłącznie backendowcem. Nawet znani backend "nyndżas ;)" coś klepią we froncie od czasu do czasu. Mnie osobiście nie boli podpinanie danych w gotowych komponentach, no i czasmai jakiegoś podstawowego css wklepać, albo prosty komponent dokleić to nawet spoko jest, kiedyś wszyscy byli backendowcami a w jsp czy jsf musieli robić z tego co słyszałem.
Natomiast ostre siedzenie we froncie pół na pół z backendem to jest porażka i faktycznie tylko osoby z naprawde mocnymi predyspozycjami, chęciami i czasem mogą być dobre w obu. Znakomita większość po porstu będzie bardzo średnia w obu. Ja raczej bym był bardzo średni :D

@Prędki_Lopez: no w sumie ja też bym mógł przy pomocy Bootstrapa napisac jakąs statyczną stronke HTML, albo jakbym dołączył do projektu gdzie jest ReactJS stosując stackoverflow-driven development i copy-and-paste-development też coś zrobić. Tyle że nie robi to w moim uznaniu ze mnie żadnego full stacka :)
W sumie mnie najbardziej razi myśl o tym konfigurowaniu narzedzi do budowania JS-a...

@scibi92: W Bootstrapie to nie ma problemu klikać :) Narzędzia do budowania .... to jest to, mi spędzają sen z powiek. Robiłem w projektach gdzie na raz jest angular2 i AngularJS, npm, bower, yarn razem spięte. No niestety, ale tak to zawile porobione, że ja przy moim doświadczeniu to dalej prawie nic z tego nie wiem. I najgorsze, że cały czas dochodza nowe i każde "wspanialsze od poprzedniego"

Backendowiec, który nie ma rozsądnego pojęcia o froncie bywa szkodliwy. Np. robi CRUDy, chociaż nikt go o to nie prosi (standard).
IMO warto jedną sensowną technologię front znać, jeśli chcesz robić sensowny backend.
Pomaga to też w ogarnieciu frontendowców, czy np. nie odwalają jakieś fuszerki.

Dodatkowo wiele konceptów z frontu przenika i stosuje się na backendzie. Bez tego może Ci się wydawać, że backend jest stabilny, cały czas używane są te same technologie i nic się nie dzieje.
IMO w javie backend (jvm backend) powoli robi się bąłagan taki prawie taki jak we froncie JS. Tylko nie wszyscy to jeszcze zobaczyli.
Ten bajzel to bardzo pozytywna sprawa. Świadzy o tym, że jakiś postęp jest.

Tak z tego bałaganu dostrzegam zmiany co chwila, odrobinke jak na froncie. Oby na lepsze :) Tylko teraz nadąż za pędem technologicznym w obu warstwach. Też uważam, że pojęcie trzeba mieć jakieś rozsądne i do tego dążyłem od początku. Tutaj chodziło mi raczej o to, że bycie 50/50 jest przegięciem w moim odczuciu. Jak mam robić 50/50 lub no 60/40 na korzyść backendu w projekcie, który ma swój własny framework do css, less, dopisywać swój własny css do tego, ponadto naraz jest pisany w Angular2 i JS i czasami jeszcze coś innego do tego to ja osobiście dostaje zawrotu głowy. Skacze z technologii do technologii, wszystko po 1 raz, jak tu byc dobrym w czymkolwiek? Zaprzedać duszę i nie musieć spać tylko się uczyć ;) Już pomijam backend w postaci mikroserwisów na aws, które tez trzeba ogarniać. Too much. IMHO robiąc takie coś i zarabainie nawet tych 20-25tys nie do końca sie opłaca bo te dodatkowe 5-7 tys nie zwróci mi życia :)

IMO w javie backend (jvm backend) powoli robi się bąłagan taki prawie taki jak we froncie JS. Tylko nie wszyscy to jeszcze zobaczyli.

Możesz to uzasadnić?

Aventus napisał(a):

Duzy produkt oparty o mikroserwisy niekoniecznie oznacza kilkadziesiat aplikacji UI.

Tego nie sugerowałem. Chodizło mi o to, że jak jest dużo skomplikowanych UI, to fullstackowcy moga je co najwyżej zepsuć.

Ponadto UI mozna rozsadnie podzielic na odpowiedzialnosci, tak ze czesc mikroserwisow ma odpowiadajacy im "lekki" front- komponenty, ktore nastepnie sa skladane w calosc w dedykowanym serwisie (aplikacji UI).

Być może, chociaz nie łapię o co chodzi, pewnie dlatego, że nie umiem sobie wyobrazić gdzie by to miało mieć zastosowanie. Użytkownik oczekuje jednej aplikacji GUI - ma się ona sama poskładać z różnych kawałków dostarczonych przez różne teamy?

Prędki_Lopez napisał(a):

Tak jak patrzę po odpowiedziach, to jednak przeważa to, że bardzo ciężko być tylko i wyłącznie backendowcem.

Dla jednych ciężko, dla mnie to prawie jak raj. ;)

jarekr000000 napisał(a):

Backendowiec, który nie ma rozsądnego pojęcia o froncie bywa szkodliwy. Np. robi CRUDy, chociaż nikt go o to nie prosi (standard).

Programista robi to, co zleca BA. Jak BA zleca CRUDa, albo nie ma BA i programiści robią co chcą, to jest problem procesowy.

IMO warto jedną sensowną technologię front znać, jeśli chcesz robić sensowny backend.
Pomaga to też w ogarnieciu frontendowców, czy np. nie odwalają jakieś fuszerki.

Najpierw wymagania biznesowe, potem front. To po co w ogóle podział na różne zawody, skoro wszystko ma i tak robić jedna osoba?

Ten bajzel to bardzo pozytywna sprawa. Świadzy o tym, że jakiś postęp jest.

Dziwne, że w prawdziwych branżach inżynierskich dąży się do porządku, tylko w IT syf uznaje się za postęp.

@somekind

Być może, chociaz nie łapię o co chodzi, pewnie dlatego, że nie umiem sobie wyobrazić gdzie by to miało mieć zastosowanie. Użytkownik oczekuje jednej aplikacji GUI - ma się ona sama poskładać z różnych kawałków dostarczonych przez różne teamy?

Wbrew pozorom- tak! Przy dużych projektach stosujących DDD, te same praktyki (a przynajmniej większość) można zastosować w warstwie prezentacji. Nadal mamy jedną aplikacje UI, ale jest ona po prostu zbiorem komponentów UI pochodzących z różnych bounded contexts (nie znam polskiego odpowiednika). Z perspektywy użytkownika jest to jedno i to samo UI- tak samo jak system z którego użytkownik korzysta wygląda na jedno wielkie "coś" co po prostu działa. Pod spodem natomiast mamy podział na odpowiedzialności, i komponenty UI. Dla przykładu- koszyk w sklepie online może być komponentem samym w sobie, komunikującym sie z serwisem (i co za tym idzie domeną) Koszyk, lub Zamówienie. W aplikacji UI komponent Koszyk jest jedynie zaimportowany i wstawiony w layout UI. Główna aplikacja nie "wie" jak Koszyk wykonuje swoje operacje, oraz z jakim serwisem się komunikuje.

Dziwne, że w prawdziwych branżach inżynierskich dąży się do porządku, tylko w IT syf uznaje się za postęp.

Mi się wydaję, żę programiści sami sobie taki los zgotowali. Czasami odnosze wrażenie że wszyscy( albo wiekszość) uczą się co chwila nowych narzędzi i technologii, w nic nie zagłebiając się na porządnie. Mam wrażenie, że jest takie przekonanie jakieś wśród ludzi, że im lepszy programista tym x więcej technologii potrafi.

Ale czemu IT nie jest "prawdziwą branżą inżynierską"? Mam inne wykształcenie inżynierskie i kompletnie się z tym nie zgadzam. Wiekszość stanowisk "inżynierskich" w polsce nie ma związku z jakimś szczególnym inżynierowaniem. Na przykład wielu, a raczej wiekszość inżynierów mechaniki budowy maszyn jest po porstu mechanikami tylko, że naprawiaja silnik w tokarce konwencjonalnej a nie samochodowy ;)

scibi92 napisał(a):

IMO w javie backend (jvm backend) powoli robi się bąłagan taki prawie taki jak we froncie JS. Tylko nie wszyscy to jeszcze zobaczyli.

Możesz to uzasadnić?

Przez ileś lat mainstream był bardzo stabilny servlety i frameworki oparte o nie. strusts, jsf, spring-mvc.
Teraz nawet w bankach powoli wchodzi make jar not war i możliwości jest dużo więcej.
Kotlin wprowadza całe tony frameworkow do wszystkiego (db, front etc.)
W Scali jest distępnych kilka alternatywnych stosów technologicznych.
A do tego jeszcze Clojure i pewnie coraz więcej Haskella.

Wiadomo, że z punktu ludzi, którzy mają ambicję doskonalić się we wkręcaniu śrubki numer 8 oznacza to bałagan.
Po prostu, albo możemy robić według dobrze dopracowanych reguł ucząc się z książek naszych dziadów.
Albo pracujemy w IT i jak na coś jest reguła to zamykamy ją w odpowiedniej abstrakcji. Konsekwencja tego jest taka, że co chwilę mamy coś nowego co jest jeszcze słabo opisane i czasem robimy jakieś wtopy ;-)

@jarekr000000: zgadzam się, szczerze mówiąc sam zauwazyłem bardzo dużą zmianę w podejściu do tworzenia oprogramowania u mnie(choć ja i tak mam buntowniczy charakter w sensie pozytywnym) ale jednak dalej mainstream to mainstream. Tak powstają nowe technologie, tak ludzie zmieniają podejście, tylko że to garstka... Spróbuj powiedziec ludziom żeby użyli Either zamiast rzucania bezsensownych wyjątków (bo wyjątek że input nie jest poprawny to g*wno a nie wyjątek), to Ci powiedzą że to Java a nie Scala. Sam jestem bardziej Spring-sceptyczny ale jak próbujesz wytłumaczyc ludziom że lepiej użyć normalnej kompozycji jeśli się da zamiast super aspektów to nie...
Choć tu mówie o poprzednich moich doświadczeniach, w firmie w której teraz jestem jest lepiej :)

Aventus napisał(a):

Wbrew pozorom- tak! Przy dużych projektach stosujących DDD, te same praktyki (a przynajmniej większość) można zastosować w warstwie prezentacji. Nadal mamy jedną aplikacje UI, ale jest ona po prostu zbiorem komponentów UI pochodzących z różnych bounded contexts (nie znam polskiego odpowiednika). Z perspektywy użytkownika jest to jedno i to samo UI- tak samo jak system z którego użytkownik korzysta wygląda na jedno wielkie "coś" co po prostu działa. Pod spodem natomiast mamy podział na odpowiedzialności, i komponenty UI. Dla przykładu- koszyk w sklepie online może być komponentem samym w sobie, komunikującym sie z serwisem (i co za tym idzie domeną) Koszyk, lub Zamówienie. W aplikacji UI komponent Koszyk jest jedynie zaimportowany i wstawiony w layout UI. Główna aplikacja nie "wie" jak Koszyk wykonuje swoje operacje, oraz z jakim serwisem się komunikuje.

Ok, teraz rozumiem o co Ci chodzi. To ma jak najbardziej sens, i też mi się zdarzało takie rzeczy robić. Tylko to jest tak naprawdę jeden frontend - tylko modularny.
Ja pisząc o wielu frontendach miałem na myśli wiele wiele oddzielnych GUI na wiele platform (np.: web, mobile web, Android, iOS), i różne funkcje przez nie spełniane.

Prędki_Lopez napisał(a):

Ale czemu IT nie jest "prawdziwą branżą inżynierską"?

No właśnie dlatego, że zamiast znane problemy rozwiązywać dobrze sprawdzonymi narzędziami, a swoją twórczość włożyć w rozwiązywanie nowych problemów, tu co chwilę rozwiązuje się stare problemy "nowymi" metodami i wmawia się, że to postęp.
I chyba w żadnej innej branży nie ma tyle kultu cargo połączonego ze ślepym podążaniem za modą.

jarekr000000 napisał(a):

Wiadomo, że z punktu ludzi, którzy mają ambicję doskonalić się we wkręcaniu śrubki numer 8 oznacza to bałagan.

A może po prostu bałaganem jest wkręcanie śrubki numer 8 przy użyciu młotka tylko dlatego, że śrubokręt jest za mało hipsterski?

Jak bardzo technologię pcha do przodu wynajdywanie koła na nowo? Kiedyś to się powinno skończyć, żeby móc branżę uznać za poważną.

@somekind: a to też prawda. Na przykład teraz niektórzy na siłe będa próbować wpychać wszędzie programowanie funkcyjne nawet jeśli sie to tego nie nadaje. Nie wiem jaki jest sens używania FP do tworzenia GUI które musi być mutowalne.

@scibi92: FP to jeszcze nic, najgorsza jest chmura i serverless wszędzie... poprzedni TL chciał budować wpisy do logów przez Amazon Lambda.