Podział na Front i Backend czy Fullstack

Jak jest u was w pracy? Jak to wypada ogółem? Raczej podział czy raczej fullstack? Które podejście jest według was bardziej sensowne albo bardziej wydajne?

Zależy od branży w jakiej się dana firma obraca, od poziomu zleceń (czy są to templatki w wordpressie czy duże systemy) i technologii. W mniejszych projektach i tam gdzie Janusz chce zaoszczędzić może nie być tego podziału, ale nie wyobrażam sobie, żeby ludzie zajmujący się optymalizacją baz danych w takim facebooku klepali w Reakcie tak samo wydajnie jak front-endowcy.

Startup to raczej na pewno coś w rodzaju full stacka. Ale duża firma raczej podział.

A może po prostu brak oficjalnego podziału a teamy same sobie rozdzielają pracę?

to zależy. Jak masz w teamie programistów full stackowych, to full stack może mieć sens, jeśli masz programistów wyspecjalizowanych a to we frontendzie a to w backendzie, to może się skończyć na tym, że kod frontendowca klepiącego backend (albo odwrotnie - backendowca klepiącego frontend) będzie marnej jakości.

jeszcze są dalsze podziały - na samym frontendzie masz z jednej strony programowanie z drugiej strony zajmowanie się CSSem. Możesz mieć osoby, które są w tym i tym dobre, a możesz mieć osobę, która np. tylko umie programować, a CSS już nie bardzo (albo odwrotnie). Wtedy zrzucanie zarówno JS jak i CSS na jedną osobę też jest nieoptymalne.

Zależy,
jak używasz jednego języka do frontu i backendu (JS, Scala, Clojure i nie wiem co tam jeszcze) to fullstack jest fajną opcją, doświadczenie z jednego procentuje w drugim, nie masz laga przy przejściu z jednej strony na drugą, a i kod może być współdzielony częściowo. Łatwiej się dogadać z ludźmi, którzy znają obie strony, no i robisz API sam dla siebie ;) Wiadomo, że i w takim teamie jest jakiś naturalny podział - jeden woli algorytmy, drugi CRUDy, jeszcze inny CSSy (istnieje ktoś taki?), ale każdy ma pełen obraz.

U mnie w firmie jest dziewięciu fullstacków (wszyscy deweloperzy) i jest spoko, a robimy coś więcej niż templatki na Wordpressie ;)

Wydaje mi się, że to sharowanie kodu , ten sam jezyk na front i backend to w przeszłości zawsze kończyło się failem.

@ZŁoty Mleczarz
W przeszłości pewnie tak. Bo jakie tam próby były - Java i GWT?
Java średnio się transpiluje do JS bo to bardzo różne języki, stąd tyle problemów.
W przypadku Node tego problemu w ogóle nie ma.
W przypadku języków funkcyjnych (Scala.js, ClojureScript itp) taka translacja jest w miarę bezbolesna a interop z libkami JS bezproblemowy, poza tym są source mapy, więc możesz się obejść bez tykania JS nawet przy debugowaniu.

Zresztą poczytaj wypowiedzi @Wibowit o Scala.js - wygląda to nieźle.

Full stack, a potem mamy strony jakie mamy :)

Z podziałem, a ja robię jako fullstack (bo daję radę).

@Maciej Cąderek
Ostatnio słuchałem podcastu gdzie ludzie odpowiedzialni za Scala.js mówili, że kod Javascriptopwy transpilowany ze Scala.js jest 10-20 razy wolniejszy niż czysty, natywnie napisany JavaSritp, ale dodatkowo używa się jakiś optymalizatorów, dzięki którym uzyskuje się kod tylko 2-3 razy wolniejszy niż natywnie napisany JavaScript

"Full-stack means "able to break all layers of the system""

To pewnie żartobliwy cytat, ale coś w tym jest jednak. Pisanie wszystkiego naraz rodzi pokusę, że dana osoba będzie łamać wszystkie zasady projektowe dotyczące separacji różnych warstw w projekcie ("Piszę sam wszystko i wszystko mieszam ze sobą").

Oddzielanie kompetencji wymusza pewien podział architektury na pewne niezależne od siebie części. ("piszę frontend i obchodzi mnie tylko frontend, bo backend to nie jest obszar mojej kompetencji").

Z drugiej strony:

• można i powinno się samemu sobie narzucić dyscyplinę w kwestii separation of concerns itp.
• jeśli projekt dopiero się tworzy, nie ma stabilnych warstw (np. stabilne API backendu) to sztuczne oddzielenie kompetencji jest trochę bez sensu, bo i tak proces developerki tak czy siak włącza wszystkie warstwy (tzn. owszem, można pisać całkowicie niezależnie frontend od backendu, technicznie to nie problem jakieś mocki napisać - ale raczej chodzi mi o komunikację, ustalenie tego jak ma działać aplikacja jako całość - jeśli frontendowiec siedzi tylko w swojej działce, backendowiec w swojej, to potem może się okazać, że wizja całego projektu jest kompletnie inna u tych ludzi - np. frontendowiec zrobił jakieś mocki i je wyświetlił, a okazuje się, że backendowiec w ogóle inne dane wystawia itp. Jednak tutaj widzę poważne wady podejścia, że każdy siedzi w swoim poletku i nie ma pojęcia jak wygląda reszta apki)

Więc i tak wychodzi na to, że "to zależy" ;)

Czasem nawet nie pisząc kodu, warto być biernym backendowcem czy biernym frontendowcem (np. moim zdaniem graficy powinni być co najmniej biernymi frontendowcami, czyli osobami, które rozumieją frontend ale niekoniecznie go piszą - może wtedy przestali by wymagać jednocześnie pixel perfect oraz RWD, bo by wiedzieli, że się nie da do końca...).

Przy pewnej skali projektu i najwyższym poziomie profesjonalizmu ciężko czasem działać inaczej niż w separacji.

Gdy jest podzial... To przeciez jedni i drudzy powinni Najpierw ustalic kontrakt api a pozniej implementowac dopiero...

Jestem z pewnością subiektywny - ponieważ od zawsze gram JOATem.

Ale krótko - dobry frontendowiec może niewiele wiedziec o backendzie i być przydatny.
Dobry backendowiec, który nie zna się dobrze na froncie jest po prostu przeszkodą dla frontendowców (prawdziwa zakała).
(Czyli ma sens - zasadniczo jak projekt nie ma frontu (bywa)).

Normalnie jednak backendowcy nie znają się, a projekty mają front. Co gorsza z backendowców wyrasta mnóstwo architektów, którzy są potem mistrzami w tworzeniu nieprzydatnej architektury. I mamy nudne i powolne UI oraz wojenki pomiędzy front i back.

Co do znania się na frontendzie jeśli to web - to będąc zatwardziałym backend boyem nadal warto znać (obecnie: koniec 2016)
angular 2, react, http i ws, html ( naprawdę), js/ts (naprawdę znać) i CSS -to ostatnie zaskakuje nawet mnie - ale tak wyszło.

Co do "naprawdę znać" - tak po prawdzie to dramatyczna większość web frontendowców ( nawet takich z wieloletnim doświadczeniem ) nie zna ani JS ani HTML. A CSS to już dramat. (Umiejętność poprawienia marginesu w IE 9 oraz zrobienie cool animacji - to nie jest znajomość CSS).

Co do pracy w małej firmie - jeśli jesteś JOATem (full stack++) - to mega przydatne.
Jeśli pracujesz w korpo - to stajesz się legendą bardzo szybko (potwierdzone :-) ).

@jarekr000000
Co masz na myśli pisząc "stajesz się legendą" w korpo? Sam jestem full stackiem i akurat ta umiejętność pomogła mi wybić się do czołówki software developerów w dwóch ostatnich korpo. Byli backendowcy, którzy nie dotkną JS bo oni "zawsze w Javie" pisali, są frontendowcy, którzy nie dotkną się backendu, bo "bebechy ich nie interesują" i właśnie tacy ludzie stają się przeszkodą. Przychodzi fullstack i okazuje się, że potrafi umiejętnie łączyć jedno z drugim, a jeśli chwilowo więcej pracy jest tylko we froncie to nie czuje się jak piąte koło u wozu.

Wklejam to chyba zawsze w tego typu tematach, więc tak tylko dla przypomnienia: http://andyshora.com/full-stack-developers.html

Ponoć Gotfryd Leibniz był ostatnim fullstackiem, potem wszystko zrobiło się znacznie bardziej skomplikowane. No, ale zawsze można pominąć 2/3 zagadnień, uznać znaną sobie 1/3 za całość i określić się tym mianem. To wiele upraszcza.

No i generalnie, ludzie nawet zatrudniani jako fullstack, często preferują jakiś rodzaj programowania, więc np. wybierając projekty/zadania w firmie, biorą to, co lubią bardziej. Więc taki trochę złudny ten brak podziału. No, ale oczywiście taki Maruś umi wszystko, i ładnie zrobi layout na tabelce, i ładnie poskleja pięknego SQLa ze stringów. W końcu jest tym fullstack senior principal leadem czy jakoś tak.

W razie jakby sarkazm nie był czytelny - nazwa stanowiska ze stopki w firmowym mailu, jaka by mądra nie była, nie gwarantuje, że człowiek cokolwiek umie.

Dla mnie podział jest jak najbardziej sensowny. Nie chciałbym być operowanym przez chirurga, który generalnie to jest proktologiem, ale coś tam zdarzyło mu się w innym szpitalu pozszywać parę osób i nikt nie umarł (później okazałoby się, że zszywał w ramach autopsji...). Podobnie jest z programowaniem- to zbyt rozległa dziedzina, żeby naprawdę być ekspertem tych dwóch rzeczy naraz.

Wydaje mi sie, że wszystko zalezy od skali.

Mały projekt, fullstackowanie - why not?

Ale ogromna skala to raczej wątpliwe jeśli ktoś więcej robi tuningu JVMa to na drugo dzień przesuwa buttony o 5 pikseli w lewo....