Fullstack - nieunikniona przyszłość?

2

Jestem .net devem pracującym na backendzie od ponad 3 lat. W zespole mamy dedykowane osoby od backendu i frontu.

Regularnie śledzę rynek i zdecydowana większość ogłoszeń dla .net developerów jest aktualnie dla fullstacków. Szczerze jak widzę w ilu zagadnieniach jeszcze jestem zielony jeśli chodzi o backend to nie wyobrażam sobie potrafić drugie tyle i więcej jeśli chodzi o front.

Chciałbym rozwijać się w kierunku backendowym i nie zbaczać na kierunki frontowe :) Czy w dzisiejszych czasach jest to nadal możliwe?
Swoją drogą mam wrażenie, że statystycznie projekty z podziałem na deweloperów na te dwie dziedziny są generalnie lepsze technicznie a sama organizacja jest bardziej dojrzała. Fullstacki kojarzą mi się głównie z startupami i szybkim wytwarzaniem softu w softwarehousach.
Chętnie usłyszałbym Wasze zdanie jak to jest z tymi fullstackami i czy rynek idzie nieubłaganie w tym kierunku?

2
Terrored napisał(a):

Chciałbym rozwijać się w kierunku backendowym i nie zbaczać na kierunki frontowe :) Czy w dzisiejszych czasach jest to nadal możliwe?

Jest możliwe.

Swoją drogą mam wrażenie, że statystycznie projekty z podziałem na deweloperów na te dwie dziedziny są generalnie lepsze technicznie a sama organizacja jest bardziej dojrzała. Fullstacki kojarzą mi się głównie z startupami i szybkim wytwarzaniem softu w softwarehousach.

To jest nadinterpretacja.

Chętnie usłyszałbym Wasze zdanie jak to jest z tymi fullstackami i czy rynek idzie nieubłaganie w tym kierunku?

Rynek idzie w stronę No code i low code i generowania aplikacji przy pomocy AI. Nie wiem czy fulstacki są etapem pośrednim.

4

Ja się cały czas bronię przed byciem fullstackiem. Na razie wychodzi. Pracuje 10 lat. Ale czy się uda dalej to nie wiem

1

To rób backend ale hardkorowo (nie CRUDy) - moge zboczyc na frontend tylko jesli jest wybitny (np. programowanie 3d albo gier w webgl)

0

Z frontu, biorę tylko security :-D

1
Terrored napisał(a):

Regularnie śledzę rynek i zdecydowana większość ogłoszeń dla .net developerów jest aktualnie dla fullstacków.

Myślę, że ta było odkąd pamiętam, czyli jakieś 12 lat.

Szczerze jak widzę w ilu zagadnieniach jeszcze jestem zielony jeśli chodzi o backend to nie wyobrażam sobie potrafić drugie tyle i więcej jeśli chodzi o front.

Wcale się nie dziwię. A poza tym szkoda wątroby.

Chciałbym rozwijać się w kierunku backendowym i nie zbaczać na kierunki frontowe :) Czy w dzisiejszych czasach jest to nadal możliwe?

Myślę, że tak. Wyłącznie backendem zajmuję się dopiero od 6 lat, wcześniej byłem "fullstackiem".

Swoją drogą mam wrażenie, że statystycznie projekty z podziałem na deweloperów na te dwie dziedziny są generalnie lepsze technicznie a sama organizacja jest bardziej dojrzała. Fullstacki kojarzą mi się głównie z startupami i szybkim wytwarzaniem softu w softwarehousach.

Tak, to prawda. Softwarehouse musi mieć fullstacków, a jeszcze najlepiej niech każdy zna C#, Javę i PHP, wtedy zawsze się takiego wcisnąć jakiemuś klientowi.
Firma produktowa z kolei woli mieć specjalistów.

6

To ja jestem dinozaurem, bo pamiętam czasy kiedy nie było frontendowców i backendowców. Nagle się te terminy pojawiły i okazało się, że jestem fullstackiem. Dodatkowo zaczęły się problemy typu: "ja tego nie zrobię, bo nie umiem", "to, że nie działa to wina tego z drugiej strony" i tak przerzucanie się odpowiedzialnością kto co i jak powinien zrobić. Znając obie warstwy można po prostu to ogarnąć.

A teraz obalę najczęstszy argument o tym, że dzięki podziałowi można się bardziej wyspecjalizować w którejś dziedzinie. Owszem! Można! Ale co z tego, że użyłeś jakieś super sztuczki na backendzie i zaawansowane wzorce projektowe, jak przyjdzie taki junior i tego nie zrozumie i rozwali to wszystko robiąc spaghetti. Do 99% aplikacji jakie już prawie te dwie dekady tworzę nie potrzeba nic wyrafinowanego i same podstawowe rzeczy wystarczą, a problem głównie był z tymi, gdzie ktoś mocno wyspecjalizowany zaszalał z poziomem komplikacji zamiast trzymać rzeczy proste.

6

Zgadzam się z @wasiu.

Generalnie możesz się specjalizować w jakiejś dziedzinie (np. backend), ale od czasu do czasu rozwinąć też inne umiejętności (np. frontend, Big data, Data science, …). Nazywa się to T-shaped person. Dzięki temu zrozumiesz bolączki „drugiej strony”, będziesz tworzył lepsze rozwiązania i osiągał lepsze efekty. Zrozumiesz bigger picture. Poza tym od czasu do czasu przyjuniorzenie w jakiejkolwiek dziedzinie jest bardzo rozwijające, zapobiega Alzheimerowi i takie tam ;)

Specjalizując się tylko w jednej dziedzinie będziesz miał tendencje do tworzenia przeintelektualizowanych rozwiązań, co czasem nazywam nadpodażą skilla. W takim przypadku doradzałbym iść w leadership, aby angażować zespoły w implementację szerszej wizji.

5

Problem pt. "przyjdzie junior i rozwali" to są problemy tych samych firm, które zatrudniają fullstakców i nie mają wypracowanych podstaw kultury pracy, np. code review.

Z moich doświadczeń wynika, że firmy, w których programiści mają swoje specjalizacje raczej w ogóle nie zatrudniają juniorów, a i kultura pracy też jest taka, że nikt niczego w pojedynkę sam nie rozwali.
Ot taka różnica między firmą produktową, a software house.

6

@Charles_Ray: rozumiem że te dostawy wszystkie skille zdobywa się w pracy? Bo ktoś może chcieć mieć po prostu życie i ma cos lepszego do roboty niż uczenie się czegoś bo tak wypada.
A i mam pytanie do fullstackow - jak będzie trzeba zrobić fronted w Androidzie albo IoS to też od razu będziecie się za to zabierać? Czym to się różni od robienia frontendu w JS?

1

MI też wydaje się, że jak backandowiec ogarnia trochę frontend to nie jest to złe. Ja sam rozwijam się w backendzie, ale dla funu jakieś tam proste apki w React/Angular popełnijem i uważa, że to było cenne doświadczenie bo łatwiej mi się z frontami dogadać. Czasami wpadają też proste taski, gdzie 90% to backend ale na froncie trzeba dodać jakiś guziczek czy inną kontrolkę i głupio wtedy zaraz fronta w to angażować. Dochodzą kwestie typu deploye, gdzie trzeba umieć zbudować front "w locie" itp.

Ogólnie uważam, że jest to jakiś logiczny etap w rozwoju kariery, że oprócz skilowania się w swojej działce dodajemy też trochę skilli z innego poletka. Taki typowy fullstack, co sam ciągnie cały projekt to faktycznie możliwe chyba tylko w jakichś małych apkach, ale podstawy warto znać.

1
Terrored napisał(a):

Jestem .net devem pracującym na backendzie od ponad 3 lat. W zespole mamy dedykowane osoby od backendu i frontu.

Regularnie śledzę rynek i zdecydowana większość ogłoszeń dla .net developerów jest aktualnie dla fullstacków. Szczerze jak widzę w ilu zagadnieniach jeszcze jestem zielony jeśli chodzi o backend to nie wyobrażam sobie potrafić drugie tyle i więcej jeśli chodzi o front.

Chciałbym rozwijać się w kierunku back-endowym i nie zbaczać na kierunki frontowe :) Czy w dzisiejszych czasach jest to nadal możliwe?

Oczywiście, że jest to możliwe i to nie jest żaden problem. Wygląda na to, że nawet nie zdajesz sobie sprawy z tego jak dużo można umieć i wiedzieć.
Programista, który potrafi "ogarnąć" cały proces tworzenia aplikacji w dzisiejszych czasach nazywana "FullStackiem" kiedyś to była jednak norma.
Oczywiście podział na front / backend istniał niemal zawsze ale to był raczej wstyd przyznać się, że nie ogarnia się "drugiej strony medalu".

W dzisiejszych czasach "korpo", w których tymczasowo nikt nie liczy się z kosztami wynikającymi z zasobów ludzkich ale i jednocześnie brakiem wyspecjalizowanych ludzi na rynku podział na mniejsze specjalizacje jest głęboko uzasadniony. Warto jednak wiedzieć, że cały świat to nie tylko aplikacje dla "korpo", a poza nim jest ogromy i coraz większy rynek małych aplikacji, które z założenia nie muszą być utrzymywane 100 lat, być top security z administracją 24h/dobę i mieć wydajność pozwalającą na obsługę100000 userów w jednym momencie.
W takim przypadku zdecydowane zalecane i najbardziej ekonomiczne będzie skorzystać właśnie z usług FullStacka, który poradzi jaką bazę i środowisko dobrać do potrzeb, a i rozumiejąc zagadnienie interfejs użytkownika skleci.
Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

Poza wszystkim rodzi się pytanie czy współcześnie programiści tkwiący w podziale front/back nigdy nie napisali samodzielnie żadnej aplikacji od początku do końca?

scibi_92 napisał(a):

A i mam pytanie do fullstackow - jak będzie trzeba zrobić fronted w Androidzie albo IoS to też od razu będziecie się za to zabierać? Czym to się różni od robienia frontendu w JS?

Choć w każdej chwili jestem gotów zacząć pisać aplikację pod iOS czy Android i to "od początku do końca" to docelowa platforma jest jednak czymś innym niż umiejętność napisania jakiejkolwiek aplikacji "od początku do końca". Nie ma kompletnej aplikacji bez frontu.

Mogę w każdej chwili napisać aplikację desktopową na iOS czy natywną na Android ale mogę też dla każdego z tych środowisk dostarczyć aplikację WEB z back-endem na serwerze i sensownym frontem, który się z nim komunikuje. Tak czy siak dostarczę odbiorcy aplikację na jego komputer niezależnie od tego czy używa Linuxa, Widowsa, Andoida czy inne applowe wynalazki.
Oczywiście poziom wiedzy w różnych obszarach jest różny ale uważam, że trzeba przynajmniej mieć pojęcie jak się za programowanie w poszczególnych systemach zabrać tak żeby to miało ręce i nogi.

3
katakrowa napisał(a):

Nie ma kompletnej aplikacji bez frontu.

Mógłbym napisać że kłamiesz, ale napiszę że rozmijasz się z prawdą. Przez ostatnie pięć lat dwa razy pracowałem w aplikacji bez frontendu. Za pierwszym razem klient chciał od nas tylko backend bo stwierdził że front mamy brzydki i napisze sobie sam lepszy. W rezultacie frontendowcy nie mieli co robić i zaczęli pisać microserwisy w Node. Jakoś nie potrafili się nauczyć Javy/Scali czy Erlanga/Elixira (języków w których była napisana reszta backendu)

Za drugim razem była to aplikacja bez frontu by design. Skaner paszportów łączył się z nami po SOAP i żadnego frontu dla użytkowników nie mieliśmy.

0
KamilAdam napisał(a):
katakrowa napisał(a):

Nie ma kompletnej aplikacji bez frontu.

Mógłbym napisać że kłamiesz, ale napiszę że rozmijasz się z prawdą. Przez ostatnie pięć lat dwa razy pracowałem w aplikacji bez frontendu. Za pierwszym razem klient chciał od nas tylko backend bo stwierdził że front mamy brzydki i napisze sobie sam lepszy. W rezultacie frontendowcy nie mieli co robić i zaczęli pisać microserwisy w Node. Jakoś nie potrafili się nauczyć Javy/Scali czy Erlanga/Elixira (języków w których była napisana reszta backendu)

Jeśli celem jest stworzenie API to ok. Oczywiście są API, które w założeniach nie mają mieć "okienek" bo są tylko po to by serwować jakieś dane ale to jedynie podgrupa z wszystkich aplikacji. ...Chociaż w sumie ta działa dla API co gadają z innymi API wcale nie jest taka mała... Zatem masz rację.

Mając jednak w zamyśle, sytuację gdy piszemy API stricte dla front-endu wcześniejsze opinie podtrzymuję :-)

1

Full stack jest idealny w małych i prostych projektach, bo tam nie traci się za dużo na braku specjalizacji, a sporo oszczędza na zlikwidowaniu konieczności dogadywania każdej pierdoły. Podobnie tam gdzie jedna z tych części jest mała i prosta i zatrudnienie frontend only developera nie ma sensu, bo brakuje dla niego roboty na cały etat, czyli w koniec końców lepiej zrobić to samodzielnie niż czekać aż komuś gdzieś się zwolni miejsce w grafiku. W dużych i złożonych projektach z mojego punktu widzenia optymalne jest utrzymywanie t-shape, czyli są ludzie specjalizujący się w czymś, ale każdy z nich ma przynajmniej podstawowe kompetencje w innych dziedzinach. Daje to sporo korzyści - minimalizacja bus factor, zrozumienie problemów po obu stronach, możliwość wrzucenia ludzi w część projektu, która jest akurat pilna.

2
hadwao napisał(a):

MI też wydaje się, że jak backandowiec ogarnia trochę frontend to nie jest to złe.

Oczywiście, że nie jest złe. Generalnie każda wiedza i umiejętności są dobre. Tylko nie dorabiajmy teorii, że koniecznie każdy musi.

Ogólnie uważam, że jest to jakiś logiczny etap w rozwoju kariery, że oprócz skilowania się w swojej działce dodajemy też trochę skilli z innego poletka.

Mhm, tylko w dzisiejszych czasach tych poletek jest o wiele więcej niż dwa.

katakrowa napisał(a):

Programista, który potrafi "ogarnąć" cały proces tworzenia aplikacji w dzisiejszych czasach nazywana "FullStackiem" kiedyś to była jednak norma.
Oczywiście podział na front / backend istniał niemal zawsze ale to był raczej wstyd przyznać się, że nie ogarnia się "drugiej strony medalu".

No właśnie, kiedyś.
Kiedyś nie było tylu języków, technologii, platform docelowych, oraz sposobów tworzenia i dostarczania aplikacji.

Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy, a swoje błędy próbuje przerzucić na innych. Backend wysyła i przyjmuje dane, co z tym zrobi frontend to jest sprawa frontendu. A jeśli coś jest nie tak w kwestii UX, to pretensje trzeba mieć do analityków, ownerów i managerów.
To brzmi równie sensownie jak jeśli nie umiesz wydobywać gazu ziemnego i wytapiać patelni, to nie zrobisz dobrej jajecznicy i odwrotnie.

Poza wszystkim rodzi się pytanie czy współcześnie programiści tkwiący w podziale front/back nigdy nie napisali samodzielnie żadnej aplikacji od początku do końca?

To nie jest kwestia tego, co kto zrobił, albo co umie robić, tylko tego, co chce robić zawodowo przez kilkadziesiąt godzin w tygodniu.

4
somekind napisał(a):

Zresztą nie raz było tu już pisane, że nie rozumiejąc back-endu nie zrobisz dobrego front-endu i odwrotnie.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy, a swoje błędy próbuje przerzucić na innych. Backend wysyła i przyjmuje dane, co z tym zrobi frontend to jest sprawa frontendu. A jeśli coś jest nie tak w kwestii UX, to pretensje trzeba mieć do analityków, ownerów i managerów.

To stwierdzenie jest tak bardzo oderwane od rzeczywistości, że nawet nie wiadomo jak je skomentować. Mógł na to wpaść chyba tylko ktoś, kto w życiu widział jedynie crudy.
Już kilka razy widziałem jak zespół backendowców rozmawiał z klientem i analitykami i na tej podstawie modelował dziedzinę a potem API. Z tego wychodziło tak cudowne rozwiązanie, że pierwsza stronka aplikacji mobilnej potrzebowała robić 114 zapytań, żeby pokazać kilkanaście tekstów i liczb.

Backendowiec może oczywiście nie znać front-endu i być dobrym backendowcem jeśli:
a) aplikacja nie ma frontendu zasadniczo (albo frontendy to są poboczne sprawy),
b) jeśli aplikacja ma frontent - to ogarnie, że w kwestii modelowania API to jego klientemi i panem jest właśnie frontend. Niestety jak ktoś robi całe życie CRUdy to problemu nie widzi i wpieprza się tam, gdzie nie powinien, często w czasie rozmów z klientem i analitykami proponując absurdalne rozwiązania (które potem rzutują na beznadziejny UX).

4

Przepraszam jeśli uraziłem swoją wypowiedzią, a po odpowiedzi widzę, że uraziłem bardzo, ale jeżeli ktoś widzi jednoznaczne i oczywiste powiązanie między backendem a frontendem, to znaczy, że zna chyba tylko crudy. Bo chyba tylko w crudach takie powiązanie 1:1 występuje, więc trzeba "rozumieć oba", żeby zrobić dobrze.

A rzeczywistość jednak potrafi być bardziej skomplikowana, w wielu systemach takiego powiązania nie ma. Często frontendów jest kilka-kilkanaście (per platforma lub per typ użytkownika), a backendów kilkadziesiąt jak nie kilkaset. I jeden frontend może korzystać z jednego lub wielu backendów, a te backendy korzystają z innych backendów. I są też backendy, do których użytkownik w ogóle nie ma żadnego dostępu, bo tylko przesyłają dane z jednego źródła do innego. A nawet istnieją backendy, które służą do zarządzania i monitorowania pracy innych backendów.

To tyle. Warto znać rzeczywistość - nawet jeśli samemu się w niej nie uczestniczy, żeby nie być od niej oderwanym.

jarekr000000 napisał(a):

Już kilka razy widziałem jak zespół backendowców rozmawiał z klientem i analitykami i na tej podstawie modelował dziedzinę a potem API. Z tego wychodziło tak cudowne rozwiązanie, że pierwsza stronka aplikacji mobilnej potrzebowała robić 114 zapytań, żeby pokazać kilkanaście tekstów i liczb.

Czyli kilka razy pracowałeś przy crudach w źle zorganizowanych firmach o słabej kulturze pracy.
To nie "zespół backendowców" jest od modelowania dziedziny, jeśli ktoś tak działa, to jest to właśnie działanie w oderwaniu od rzeczywistości.

0

nie wiem czy nieuniknione ale mi praca nad tylko jedną częścią wydaje się ułomna - to trochę jak granie w dwie osoby w grę na jednym komputerze gdzie jedna osoba operuje myszką a druga klawiaturą...
Byłem w sytuacji że zajmowałem się tylko frontem a backendem kto inny i musiałem często czekać aż api będzie gotowe żeby móc kontynuować, potem się okazywało że api jest tragicznie zaprojektowane albo czegoś brakuje i zaczynało się przerzucanie taska od osoby do osoby. Zdarzyło mi się też pracować tylko nad backendem podczas gdy task frontendowy dostał ktoś inny i wcale nie było bardziej różowo. W zasadzie to samo tylko od drugiej strony - wizja api które chciałby dostać frontendowiec od wizji backendowca jest często skrajnie różna. Ogólnie dużo czasu zbędnie straconego na dodatkowe meetingi i synchronizację.

No chyba że się jest głęboko w backendzie - tj. nie robimy po prostu api pod front tylko grzebiemy gdzieś głębiej w aplikacji nad jakimś przetwarzaniem danych, nie obchodzi nas wcale front i jesteśmy samowystarczalni. Wtedy praca jest ok, ale takiej jest znacznie mniej.
Tylko że to chyba się już wtedy nie nazywa backend developer, raczej data scientist / big data developer czy po prostu software engineer. Osobiście pracowałem we wszystkie trzy wymienione sposoby i muszę przyznać że ten trzeci był najprzyjemniejszy (najspokojniejszy), choć praca z frontem daje naoczne efekty pracy przy najmniejszym nakładzie i też potrafi być satysfakcjonująca.

4

Założmy że mamy osoby A i B.
Osoba A pracuje w jakiejś tam firmie X, jest jeden monolit który ewentualnie integruje się przez jakieś staromodne SOAPy albo RESTy z innymi systemami, jest fullstackiem. Ogarnia Jave, Springa, jakąs bazę SQL, Mavena (takie narzędzie do budowania, niezbyt trudne), Angulara i jakieś tam narzędzie do budowania frontu, potrafi też coś tam wyklikać w Jenkinsie.
Osoba B pracuje jako pure backend developer, w architekturze rozproszonej, ma Jave, Springa, Maven/Gradle plus jeszcze integracje zarówno REST/SOAP jak i przez systemy kolejkowe/rozproszone logi jak RabbitM lub, Kafke, ogarniać Dockera, Kubernetesa, SQL i NoSQL jak np. ElasticSearch.
Z jakiś powodów mam wrażenie że osoba A byłaby przez niektórych uznawana za jakąś lepszą, mimo że mogłaby potrzebować nawet mniej do nauki niż osoba B. Tak jak @somekind napisał i czego sam doświadczyłem jest to że istnieja aplikacje ktore nie sa nawet bezpośrednio powiązane z jakimkolwiek frontem, mogą to być nawet systemy które nasłuchują jedne topici na Kafce a na drugie coś wysyłają.

Kiedyś nie było tylu języków, technologii, platform docelowych, oraz sposobów tworzenia i dostarczania aplikacji.

Programuje stosunkowo niedługo, ale z tego co wiem frontend zaczął się rozwijać szybko stosunkowo niedawno. Wczesniej nie było aplikacji SPA jak teraz, zaawansowanych narzędzi do budowania frontu, tylko był jakiś server-side rendering albo jakieś proste JQuery.

@wasiu

robiłem frontend w Androidzie :) ciekawa odskocznia. Jakby trzeba było to pewnie i IoS'ie zrobił. To jest coś, co nas wyróżnia jako Polaków na arenie międzynarodowej ale widzę, że nowe pokolenie programistów jest dosyć mocno ograniczona pod tym względem i idzie torami zachodu - robię tylko swoje i nic więcej.

Pozwolę się odnieść do tego w poście. Po prostu niektórzy piszą że backendowcy powinni nauczyć się frontendu żeby lepiej dogadać się z frontendami. Często aplikacja mobilna tez jest frontendem, idąć takim tokiem rozumowania backendowcy powinni też uczyć się Androida.

2
obscurity napisał(a):

nie wiem czy nieuniknione ale mi praca nad tylko jedną częścią wydaje się ułomna - to trochę jak granie w dwie osoby w grę na jednym komputerze gdzie jedna osoba operuje myszką a druga klawiaturą...

Hmm, ma sens. Należy połączyć stomatologię z proktologią w jedna specjalizację, żeby nie było ułomnie.

0
scibi_92 napisał(a):

Założmy że mamy osoby A i B.

Osoba A pracuje w jakiejś tam firmie X, jest jeden monolit który ewentualnie integruje się przez jakieś staromodne SOAPy albo RESTy z innymi systemami, jest fullstackiem. Ogarnia Jave, Springa, jakąs bazę SQL, Mavena (takie narzędzie do budowania, niezbyt trudne), Angulara i jakieś tam narzędzie do budowania frontu, potrafi też coś tam wyklikać w Jenkinsie.
Osoba B pracuje jako pure backend developer, w architekturze rozproszonej, ma Jave, Springa, Maven/Gradle plus jeszcze integracje zarówno REST/SOAP jak i przez systemy kolejkowe/rozproszone logi jak RabbitM lub, Kafke, ogarniać Dockera, Kubernetesa, SQL i NoSQL jak np. ElasticSearch.

Nie ma jednostki miary faności programisty wszystko zależy od sytuacji. Jak będzie do zrobienia pilna poprawka na froncie to osoba B może okazać się całkowicie nieprzydatna i również odwrotnie. Z drugiej strony, brak kompetencji w jakimś obszarze nie nobilituje.

Z jakiś powodów mam wrażenie że osoba A byłaby przez niektórych uznawana za jakąś lepszą, mimo że mogłaby potrzebować nawet mniej do nauki niż osoba B. Tak jak @somekind napisał i czego sam doświadczyłem jest to że istnieja systemy ktore nie sa nawet bezpośrednio powiązane z jakimkolwiek frontem, mogą to być nawet systemy które nasłuchują jedne topici na Kafce a na drugie coś wysyłają.

No nie bardzo. istnieją takie komponenty systemów, bo coś gdzieś jednak te zdarzenia do Kafki wrzuca, i ktoś gdzieś je odbiera. I dopiero wtedy możemy mówić o systemie.

Kiedyś nie było tylu języków, technologii, platform docelowych, oraz sposobów tworzenia i dostarczania aplikacji.

Wydaje ci się. Programowanie i używane technologie stają się raczej prostsze np. CORBA -> SOAP -> REST, ASM -> C++ -> Java -> PHP -> NodeJS. Rośnie za to złożoność systemów

Programuje stosunkowo niedługo, ale z tego co wiem frontend zaczął się rozwijać szybko stosunkowo niedawno. Wczesniej nie było aplikacji SPA jak teraz, zaawansowanych narzędzi do budowania frontu, tylko był jakiś server-side rendering albo jakieś proste JQuery.

Server side rendering to nie frontend?

@wasiu

robiłem frontend w Androidzie :)
Pozwolę się odnieść do tego w poście. Po prostu niektórzy piszą że backendowcy powinni nauczyć się frontendu żeby lepiej dogadać się z frontendami. Często aplikacja mobilna tez jest frontendem, idąć takim tokiem rozumowania backendowcy powinni też uczyć się Androida.

Wymagania odnośnie API potrzebnego w dowolnym rodzaju UI klienta (Android, OPA, Desktop) są zaskakująco zbieżne. Jeżeli masz pojęcie o którymkolwiek z nich, to jest już dobrze. I ja nawet rozumiem alergię na frontend - specyficzna praca gdzie 90% czasu to dłubanina i przesuwanie budek o 2px w którąś tam stronę, żeby były bardziej amazing, natomiast mam alergię na podejście "napisałem nie wiem po co, u mnie działa". I tak są systemy/komponenty gdzie nie ma frontu w znaczeniu UI, ale zawsze masz coś co jest skierowane na zewnątrz (wspomniane przez ciebie API, event bus, kolejki itp.) i warto by było, żeby te elementy odpowiadały potrzebom kogoś, kto ich będzie używał.

2
piotrpo napisał(a):

Nie ma jednostki miary faności programisty wszystko zależy od sytuacji. Jak będzie do zrobienia pilna poprawka na froncie to osoba B może okazać się całkowicie nieprzydatna i również odwrotnie. Z drugiej strony, brak kompetencji w jakimś obszarze nie nobilituje.

Czyli wypadałoby umieć każdy język, każdy framework i każdą bibliotekę, bo inaczej zawsze ktoś może zarzucić brak kompetencji.

No nie bardzo. istnieją takie komponenty systemów, bo coś gdzieś jednak te zdarzenia do Kafki wrzuca, i ktoś gdzieś je odbiera. I dopiero wtedy możemy mówić o systemie.

Masz rację co do terminów, tylko co to zmienia? Są backendy bez frontendów, pogląd, że zawsze jest jakaś powiązanie jednego z drugim jest oderwany od rzeczywistości.

Wydaje ci się. Programowanie i używane technologie stają się raczej prostsze np. CORBA -> SOAP -> REST, ASM -> C++ -> Java -> PHP -> NodeJS. Rośnie za to złożoność systemów

Jakich frameworków frontendowych, usług chmurowych i message brokerów używałeś w 2005? Jak wdrażałeś wielokomponentowe systemy?

0
somekind napisał(a):

Czyli wypadałoby umieć każdy język, każdy framework i każdą bibliotekę, bo inaczej zawsze ktoś może zarzucić brak kompetencji.

Nie, ale wypada mieć minimum wiedzy o różnych obszarach w których działa twój projekt jako całość.

Masz rację co do terminów, tylko co to zmienia? Są backendy bez frontendów, pogląd, że zawsze jest jakaś powiązanie jednego z drugim jest oderwany od rzeczywistości.

Ale każdy z tych backendów, jak je nazywasz ma swoje UI (nie koniecznie graficzne), czyli sposób w jaki komunikuje się z otoczeniem. Otoczenia nie interesuje co masz w środku, dopóki robi to co ma robić. Ale to otoczenie jest wybitnie zainteresowane tym, w jaki sposób komunikować się z tym komponentem. Dlatego warto wiedzieć co jest tym otoczeniem i mieć ogólne pojęcie co jest tam potrzebne. Według mnie, ideałem jest kiedy "otoczenie" zaprojektuje idealny wg. niego interface pisząc np. testy integracyjne. Dostajesz testy, generujesz sobie np. endpointy i piszesz adapter, który ma dostosować to co masz wewnątrz do tego co jest oczekiwane. Na koniec masz jasną sytuację, kiedy wiadomo kto dał ciała.

Jakich frameworków frontendowych, usług chmurowych i message brokerów używałeś w 2005? Jak wdrażałeś wielokomponentowe systemy?

JSP, JSF. Wszystko co masz na froncie w tej chwili jest łatwiejsze od tego co było. I moim skromnym zdaniem, właśnie uproszczenie się technologii do rozwoju oprogramowania umożliwiło wzrost złożoności systemów, bo dodanie nowego mikroserwisu dzisiaj ogranicza się do utworzenia nowego projektu w czymkolwiek i wpisania go do helm charta.

4
piotrpo napisał(a):

Nie, ale wypada mieć minimum wiedzy o różnych obszarach w których działa twój projekt jako całość.

Raczej moje projekty. I mam "minimum wiedzy o obszarach", a nawet tak średnio do maksimum wiedzy, bo wszystkie są backendowe, może jakieś 10% jest bezpośrednio używane przez FE.

A jeśli jako "projekt" miałeś na myśli "system", to znaczy, że powinienem znać na webie, aplikacjach mobilnych, i kilkunastu systemach ecommerce, głównie tworzonych w PHP. No na pewno. :D

Ale każdy z tych backendów, jak je nazywasz ma swoje UI (nie koniecznie graficzne), czyli sposób w jaki komunikuje się z otoczeniem. Otoczenia nie interesuje co masz w środku, dopóki robi to co ma robić. Ale to otoczenie jest wybitnie zainteresowane tym, w jaki sposób komunikować się z tym komponentem. Dlatego warto wiedzieć co jest tym otoczeniem i mieć ogólne pojęcie co jest tam potrzebne. Według mnie, ideałem jest kiedy "otoczenie" zaprojektuje idealny wg. niego interface pisząc np. testy integracyjne. Dostajesz testy, generujesz sobie np. endpointy i piszesz adapter, który ma dostosować to co masz wewnątrz do tego co jest oczekiwane. Na koniec masz jasną sytuację, kiedy wiadomo kto dał ciała.

To nie odróżniasz UI od punktu styku? Event kafki to dla Ciebie UI? API to dla Ciebie UI?
Czego w ogóle dotyczą pozostałe truizmy, które tu napisałeś? Przecież to oczywiste, że dwa komponenty muszą być skomunikowane i trzeba ustalić format tej komunikacji, i obie strony muszą go znać. Ale to jest jakiś argument na potwierdzenie tezy, że backendowiec musi znać frontend, żeby zrobić dobrze backend? No nie bardzo.

JSP, JSF. Wszystko co masz na froncie w tej chwili jest łatwiejsze od tego co było. I moim skromnym zdaniem, właśnie uproszczenie się technologii do rozwoju oprogramowania umożliwiło wzrost złożoności systemów, bo dodanie nowego mikroserwisu dzisiaj ogranicza się do utworzenia nowego projektu w czymkolwiek i wpisania go do helm charta.

A które z nich to chmura, a które message broker? ;]

Pojedyncze technologie się może upraszczają, ale jest ich po prostu więcej. Znacznie więcej, więc złożenie wszystkiego do kupy jest niekoniecznie łatwiejsze niż ileś lat temu.

3

Jak zaczynałem to klepałem frontend na równi z backendem.
Po 3 latach pisałem backend, czasami poprawiałem frontend.
Po kolejnych 3 latach pisałem backend, ale UI do aplikacji widywałem codziennie.
Teraz przez dwa lata UI widziałem tylko raz, na jakiejś prezentacji.

Jeśli już jakieś role w projekcie mają się merge'ować to:

  • frontendowcy będą przejmować obszar UI/UX
  • backendowcy będą przejmować obszar devops
0
somekind napisał(a):

A jeśli jako "projekt" miałeś na myśli "system", to znaczy, że powinienem znać na webie, aplikacjach mobilnych, i kilkunastu systemach ecommerce, głównie tworzonych w PHP. No na pewno. :D

Chyba nie jasno piszę. Moim zdaniem, jeżeli tworzysz backend do którego będzie potrzebny frontend, to albo frontend ma decydować o kształcie tego API, albo ty powinieneś mieć odrobinę doświadczenia w dowolnej technologii frontendowej i wiedzieć co ten konkretny frontend ma zrobić. To, że dla większości pracodawców będziesz warty więcej mając jakąś wiedzę spoza swojej wąskiej działki jest raczej oczywiste

Ale każdy z tych backendów, jak je nazywasz ma swoje UI (nie koniecznie graficzne), czyli sposób w jaki komunikuje się z otoczeniem. Otoczenia nie interesuje co masz w środku, dopóki robi to co ma robić. Ale to otoczenie jest wybitnie zainteresowane tym, w jaki sposób komunikować się z tym komponentem. Dlatego warto wiedzieć co jest tym otoczeniem i mieć ogólne pojęcie co jest tam potrzebne. Według mnie, ideałem jest kiedy "otoczenie" zaprojektuje idealny wg. niego interface pisząc np. testy integracyjne. Dostajesz testy, generujesz sobie np. endpointy i piszesz adapter, który ma dostosować to co masz wewnątrz do tego co jest oczekiwane. Na koniec masz jasną sytuację, kiedy wiadomo kto dał ciała.

To nie odróżniasz UI od punktu styku? Event kafki to dla Ciebie UI? API to dla Ciebie UI?
Czego w ogóle dotyczą pozostałe truizmy, które tu napisałeś? Przecież to oczywiste, że dwa komponenty muszą być skomunikowane i trzeba ustalić format tej komunikacji, i obie strony muszą go znać. Ale to jest jakiś argument na potwierdzenie tezy, że backendowiec musi znać frontend, żeby zrobić dobrze backend? No nie bardzo.

Napisałem wyżej o moich oczekiwaniach w stosunku do backendowca. Event kafki, który ktoś musi do ciebie wysłać, lub od ciebie odebrać, API, to sposób w jaki komunikujesz się z użytkownikiem swojego kawałka systemu. Czy nazwiesz to punktem styku, interfacem międzysystemowym, czy UI jest już raczej kwestią semantyczną.

JSP, JSF. Wszystko co masz na froncie w tej chwili jest łatwiejsze od tego co było. I moim skromnym zdaniem, właśnie uproszczenie się technologii do rozwoju oprogramowania umożliwiło wzrost złożoności systemów, bo dodanie nowego mikroserwisu dzisiaj ogranicza się do utworzenia nowego projektu w czymkolwiek i wpisania go do helm charta.

A które z nich to chmura, a które message broker? ;]

Po co ci MB jako osobna usługa w monolicie i wystarczy jeden bean? Zreszta już wtedy były serwery kolejek np.IBM MQ, nie pamiętam czy JMS weszło wtedy, czy chwilę później.

Pojedyncze technologie się może upraszczają, ale jest ich po prostu więcej. Znacznie więcej, więc złożenie wszystkiego do kupy jest niekoniecznie łatwiejsze niż ileś lat temu.

Moja hipoteza, że jest to tak samo trudne jak kiedyś, bo granice złożoności systemu informatycznego są wyznaczane głównie przez granice rozumienia tego systemu przez twórców. Czyli my jesteśmy w stanie kumać tyle co kiedyś, ale dzięki rozwojowi inżynierii programowania, technologii i ideii typu DevOps nieco później dochodzimy do ściany.

3
piotrpo napisał(a):

Chyba nie jasno piszę. Moim zdaniem, jeżeli tworzysz backend do którego będzie potrzebny frontend, to albo frontend ma decydować o kształcie tego API, albo ty powinieneś mieć odrobinę doświadczenia w dowolnej technologii frontendowej i wiedzieć co ten konkretny frontend ma zrobić.

Mogę mieć całe doświadczenie świata na frontendzie, ale i tak nie wymyślę, czego chce biznes, ani czego chcą użytkownicy. To nie programiści tworzą wymagania!

To, że dla większości pracodawców będziesz warty więcej mając jakąś wiedzę spoza swojej wąskiej działki jest raczej oczywiste

I, że niby backend to jest wąska działka?
To tak jakby powiedzieć, że frontend to przesuwanie checkboxów. ;]

Napisałem wyżej o moich oczekiwaniach w stosunku do backendowca. Event kafki, który ktoś musi do ciebie wysłać, lub od ciebie odebrać, API, to sposób w jaki komunikujesz się z użytkownikiem swojego kawałka systemu. Czy nazwiesz to punktem styku, interfacem międzysystemowym, czy UI jest już raczej kwestią semantyczną.

Nie, nie jest kwestią semantyczną, bo my tu o wiedzy frontendowej rzekomo backendowcom potrzebnej rozmawiamy, nie o integracji systemów. UI to frontend jest.

Po co ci MB jako osobna usługa w monolicie i wystarczy jeden bean? Zreszta już wtedy były serwery kolejek np.IBM MQ, nie pamiętam czy JMS weszło wtedy, czy chwilę później.

No właśnie do tego dążę - sam widzisz, że kiedyś były monolity, z backendem i frontendem w jednej jednostce deploymentu. Kiedyś nie było smartfonów. Kiedyś nie było tyle telemetrii, i analizowania zachowań użytkowników. Kiedyś nie było wielu rzeczy, które są teraz. Gadanie, że teraz można działać tak jak kiedyś świadczy o oderwaniu od rzeczywistości.

Moja hipoteza, że jest to tak samo trudne jak kiedyś, bo granice złożoności systemu informatycznego są wyznaczane głównie przez granice rozumienia tego systemu przez twórców. Czyli my jesteśmy w stanie kumać tyle co kiedyś, ale dzięki rozwojowi inżynierii programowania, technologii i ideii typu DevOps nieco później dochodzimy do ściany.

Tak, oczywiście. Przecież oprogramowanie jest równie funkcjonalne i powszechne jak 15 lat temu. Nic się kompletnie nie zmieniło. :)

0

Mam wrażenie, że kluczysz, a nie odnosisz się do meritum.

@somekind:

I, że niby backend to jest wąska działka?
To tak jakby powiedzieć, że frontend to przesuwanie checkboxów. ;]

Gdzie napisałem, że backend to wąska działka? Jeżeli piszesz jeden z 200 kawałków tego systemu, to wtedy jest to wąska działka.

Nie, nie jest kwestią semantyczną, bo my tu o wiedzy frontendowej rzekomo backendowcom potrzebnej rozmawiamy, nie o integracji systemów. UI to frontend jest.

Odrobina abstrakcji i ból, jak ja się czepiam słówek to źle. Ok. masz rację UI to interface systemu z którym ma interakcję użytkownik (czyli CLI, tekstowe okienka, graficzne okienka, strona www, aplikacja mobilna, asystent głosowy czy guzik do włączenia inteligentnej żarówki).

No właśnie do tego dążę - sam widzisz, że kiedyś były monolity, z backendem i frontendem w jednej jednostce deploymentu. Kiedyś nie było smartfonów. Kiedyś nie było tyle telemetrii, i analizowania zachowań użytkowników. Kiedyś nie było wielu rzeczy, które są teraz. Gadanie, że teraz można działać tak jak kiedyś świadczy o oderwaniu od rzeczywistości.

Gdzie ja napisałem, że należy działać tak jak kiedyś?

Moja hipoteza, że jest to tak samo trudne jak kiedyś, bo granice złożoności systemu informatycznego są wyznaczane głównie przez granice rozumienia tego systemu przez twórców. Czyli my jesteśmy w stanie kumać tyle co kiedyś, ale dzięki rozwojowi inżynierii programowania, technologii i ideii typu DevOps nieco później dochodzimy do ściany.

Tak, oczywiście. Przecież oprogramowanie jest równie funkcjonalne i powszechne jak 15 lat temu. Nic się kompletnie nie zmieniło. :)

Ale to oczywiste, że dzisiaj systemy robią więcej i dlatego są trudne, kiedyś robiły mniej, ale nie było tez iluś tam narzędzi wspomagających zapanowanie nad tą złożonością. Nie było też takiego zrozumienia architektury systemów, procesu wytwarzania oprogramowania, a stawiając nowy element trzeba było wstawić nowy serwer do lochu, zamiast dopisać linijkę w teraformie, czy innym helmie.

1
piotrpo napisał(a):

Mam wrażenie, że kluczysz, a nie odnosisz się do meritum.

Doskonała diagnoza, tylko pacjent nie ten. :P

Przypominam, że teza główna brzmi, że backendowiec musi znać frontend, żeby zrobić dobry backend. Ja cały czas trzymam się tego tematu. I cały czas się z tym fundamentalnie nie zgadzam, bo to jest bzdura.
Żeby miało to sens, to należałoby sformułować: W organizacjach, które nie zatrudniają odpowiednich analityków ani specjalistów UX, i w projektach, których UI jest ściśle związane z backendem, wiedza na temat technologii frontendowych pozwala backendowcom być lepszymi analitykami. No i w sumie to nadal nie ma sensu (no chyba, że za trzy etaty płacą trzy pensje), ale jest przynajmniej zgodne z prawdą. :)

Gdzie napisałem, że backend to wąska działka? Jeżeli piszesz jeden z 200 kawałków tego systemu, to wtedy jest to wąska działka.

Oczywiście, trzeba wiedzieć gdzie i po co jest używany nasz kawałek systemu. Tylko zupełnie nie wiem, jaki ma z tym związek znajomość technologii frontendowych.

Jeśli w banku mam napisać moduł, który ma cyklicznie codziennie o 8 rano pobierać kursy walut z NBP i wrzucić do jakiejś kafki czy service busa event z tymi danymi, aby można było prawidłowo obliczyć opłaty za przelewy zagraniczne, to muszę znać angulara, czy react wystarczy?

Odrobina abstrakcji i ból, jak ja się czepiam słówek to źle. Ok. masz rację UI to interface systemu z którym ma interakcję użytkownik (czyli CLI, tekstowe okienka, graficzne okienka, strona www, aplikacja mobilna, asystent głosowy czy guzik do włączenia inteligentnej żarówki).

To nie jest kwestia abstrakcji i słówek tylko meritum dyskusji. Rozmawiamy o frontendzie i backendzie, nie backendzie i backendzie.

Ale to oczywiste, że dzisiaj systemy robią więcej i dlatego są trudne, kiedyś robiły mniej, ale nie było tez iluś tam narzędzi wspomagających zapanowanie nad tą złożonością. Nie było też takiego zrozumienia architektury systemów, procesu wytwarzania oprogramowania, a stawiając nowy element trzeba było wstawić nowy serwer do lochu, zamiast dopisać linijkę w teraformie, czy innym helmie.

No właśnie, kiedyś nie było iluś narzędzi - o tym piszę od początku. Teraz jest więcej narzędzi, więcej technologii, i zamiast nauczyć się bazy, języka backendowego i frontendowego trzeba nauczyć się kilkunastu technologii backendu i okolic.
Nie przeczę, że teraz łatwiej jest tworzyć złożone systemy, tylko te systemy wciąż tworzone są przez wielu ludzi, tylko ich rozkład wiedzy się zmienia na bardziej wyspecjalizowany. I to jest naturalny proces zachodzący w każdej branży.

1 użytkowników online, w tym zalogowanych: 0, gości: 1