Szerinted a frontend és a backend milyen szerepet tölt be egy átlagos projekt fejlesztésekor?

Programozás

Szerintem a backendet több emberi erőforrásba kerül lefejleszteni, és nehezebb is jó backendest találni
14% (34 szavazat)
Szerintem a backendet több emberi erőforrásba kerül lefejleszteni, de nehezebb jó frontendest találni
14% (34 szavazat)
Szerintem a frontendet több emberi erőforrásba kerül lefejleszteni, és nehezebb is jó frontendest találni
7% (16 szavazat)
Szerintem a frontendet több emberi erőforrásba kerül lefejleszteni, de nehezebb jó backendest találni
8% (19 szavazat)
Nem tudom hol van ennek a kettőnek a határa, mert nálunk mindenki full stack developer.
17% (42 szavazat)
Nem programozok / nem programoztam még csapatban
41% (100 szavazat)
Összes szavazat: 245

( sj | 2015. 08. 22., szo – 19:23 )

ez megint egy empatia szavazas?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

ok, akkor game on: azt nem tudom, hogy melyiket nehezebb talalni, de szerintem egy konkret projekt eseten lehet csak eldonteni, hogy a frontend vagy a backend lefejlesztese kerul tobbe. Mar csak azert is, mert pl. a frontend valtozasa (pl. uj gomb, input mezo, whatever) backend valtozast is vonhat maga utan (ill. forditva is igaz lehet).

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Valaki olyan helyen doglozik, ahol ralat tobb projektre, mert pl. 3 havonta masikon dolgozik. Es fel tudja merni, hogy "hat ezt a reszt ennyi ido alatt irtam volna meg, a kinezetet meg annyiu ido alatt". Kiindulasi pontnak ezek atlaga megfelelo. De ha csak egy projektet lattal eletedben, akkor rad van bizva, hogy ahhoz kepest milyennek kepzelsz egy atlagosat. Nyilvan egy szavazas sem ad 100%-os megbizhatosaggal eredmenyt, es ez utobbi miatt ez sem.

Ugyanakkor pl. aki 2 eve nem talal jo backendest az tuti szavaz, es neki ket radiogomb maradt (volt ilyen panaszkodos poszt nem is olyan reg). En meg pont hogy inkabb backendeseket ismerek, en frontendes keresesevel lennek bajban (illetve nem vagyok, csak azt mar nem bizhatom olyanra, akit ismerek). Lenyeg kivancsi vagyok, ki hogy latja ezt a helyzetet (ki szerint melyik iranyba erdemes specializalodni, hany helyen gondokodnak csak full stack-ben, ahol nem, ott melyiket talalnak nehezebben, szerintem mindegyik kerdes relevans es jovobeli dontesekre is kihathat. Nem csak az enyemekre).

( joco01 v | 2015. 08. 22., szo – 19:41 )

Teljesen rossz általánosítás, ezért egyikre sem szavazok.

A Gmail vagy FB backendjéről el (se) lehet képzelni, hány rétegből áll, és mennyire bonyolult, miközben egy max 5 osztályból álló domain modellen értelmezett CRUD stack lefejlesztése unalmas ujjgyakorlat. Frontendek terén talán nem ekkora a szórás, mert maga a frontend kissé korlátozottabb fogalom, de ott is több nagyságrend van a végletek között, és ugyanolyan nehéz tud lenni jól és szépen csinálni.

--

Mindenkinek más az átlagos projekt. Ha valaki banki szférában mozog, neki más az átlagos projekt, mint annak, aki mondjuk kisvállalkozásoknak épít webshopokat egyedi igények alapján.
Ugyanígy más az átlagos projekt annak, aki meg mondjuk marketingkampányokhoz programoz mobilappokat, facebook appokat stb. Mindenki egy más szeletét látja a piacnak, más számít neki átlagosnak.
Mondjuk egy utóbbinak egy 5-6 emberes projekt átlagos, 2-3 havi lefutással, míg egy banki szférában dolgozónak meg az 50-70 emberes projekt, ami jó pár évig/éve tart a normális.

+1, ezt akartam én is írni azzal a különbséggel, hogy én azért random szavaztam egyet.
Problémafüggő, hogy mi a nehezebb. Jó frontendet csinálni nehéz, de egy bonyolultsági szint felett a backend válik nagyságrendileg nehezebb feladattá - főleg, ha skálázódó teljesítményt kell elérni.

( persicsb | 2015. 08. 22., szo – 21:35 )

Aki full stack developer, az is pontosan tudja, hol a frontent és a backend határa, már amennyiben frontend alatt azt a szoftverkomponenst értjük, amivel emberek találkoznak és használják.

Ugyanis például egy szolgáltatás fejlesztésénél a frontend az a szolgáltatás API-ja. Azt is meg kell tervezni és jól implementálni, mint ahogy a felhasználói interakciókat, a felületeket meg kell tervezni és jól implementálni.

Szerintem amúgy felhasználói felületet tervezni nehezebb, mert sok minden olyanra kell gondolni, amire backenden annyira nem: a felhasználók különbözőek egymástól, nagyon.

Azt pedig, hogy mit nehéz találni: jó programozót nehéz találni. Platformtól, nyelvtől függetlenül. Spagettikódot minden nyelven lehet írni, függetlenül attól, hogy az éppen UI kód vagy nem UI kód.

> Aki full stack developer, az is pontosan tudja, hol a frontent és a backend határa
Én is ezt gondoltam ma délután kettő óráig.

Ekkor viszont megláttam a harmadik legnépszerűbb yeoman generátort, a react-fullstacket, és csak remélni merem, hogy a "best practice" (akármi is legyen az) nem ezt a fajta "hányjunk mindent egy könyvtárba attól függetlenül, hogy kliens- vagy szerveroldali kód" szemléletet követi /o\

Nekem mindig is lábrázásom volt a scaffolding eszközöktől.

Plusz aki szerint együtt kell kezelni a frontend és backend stacket, az is probléma. Az a jó, minél függetlenebb a két layer egymástól. Nem véletlenül találták ki az absztrakciót, ami mondjuk egy webapp FE és BE rétegei közötti esetben épp a HTTP feletti adatcsere.

( Nyosigomboc v | 2015. 08. 22., szo – 22:25 )

A jo valasz az "attol fugg". Elsosorban ugye projecttol, es nincs olyan, hogy atlagos project.
Egy vekonykliensnel a backend a nehezebb, egy olyan projectnel pedig, ahol szinte minden kliensoldalon dol el, az. (utolso komolyabb projectemnel a frontend sokkal durvabb volt, bar ez attol fugg mit szamitunk bele a backendbe)

--
Hi, welcome to Fight Club.
First of all, how did you hear about us?

( andrej_ v | 2015. 08. 22., szo – 22:29 )

Akkor már inkább fejleszteni vagy kifejleszteni..., ettől lefejlesztéstől mindíg tikkelek kicsit.

Szerintem itt jelentesarnyalati kulonbseg van. A kifejleszteni szo az mindig egy komplett, tervezessel es egyeztetesekkel egybekotott folyamatot takar, a lefeljleszteni pedig inkabb csak a tenyleges kodolasra ertendo, legalabbis azokban a szovegkornyezetekben, ahol egyszerre latom ezt a ket szot hasznalni.
--
Blog | @hron84
Üzemeltető macik

( kmARC v | 2015. 08. 23., v – 00:00 )

Arra szavaztam, hogy frontendre több erőfeszítés kell. Többen leírták már, miért nem jó a kérdés. Szerintem sem.

Én egyre "kritikusabb" vagyok azzal kapcsolatban, hogy a mindennapjaimban milyen szoftverek UI-jával érintkezek. Azt leszarom - nem is tudom - hogy az egyes programok backendje esetleg egy php-s spagetti, vagy egy haskelles formálisan verifikált 100% coverage-ű cucc... Ha a javascript nem gyors, vagy a divek szétcsúsznak, esetleg nincs kereső, akkor már kattint is el a user.

Frontendest - azt gondolnám - pont emiatt nehéz is találni. Kevés programozó érti meg, hogy a jó GUI több annál, mint hogy vizuálstudióban összekattingatom a buttont meg a checkboxot. A felületnek nyelvezete van, amit kompatibilissé kell tenni a userrel. Mindezt úgy, hogy vizuálisan konzisztens is legyen, és mindemellett gyors is. A nagy cégek ebbe ölnek rengeteg időt, energiát, pénzt (lásd MSOffice GUI redesign, Google material design, Facebook react, etc.)

( Aadaam v | 2015. 08. 23., v – 01:14 )

Valóban projekt - és emberfüggő.

Az elmúlt hónapban egy UX-logadatokat vizualizáló szoftvert készítettem. Egyetlen SQL-t táblát selectál a backend, authentikáció kb. nincs (intranet), eloszthatóság nem elvárás (valószínűtlen hogy 2-3 embernél több nézze egyszerre) - ellenben a vizualizációs kód szumma több ezer sor, kis párszáz soros javascriptekben.

Ugyanakkor mondjuk a Siri frontend-kódja nem lehet valami bonyolult (néha jön egy callback, írd ki a szöveget, meg küldd el a TTS-nek), de a backendjére kiváncsi lennék.

A frontendek bonyolódnak, egyszerűen többet várunk el a szoftverektől. és nem akarunk pilótavizsgát tenni, ha már egyszer többmagos, flash drive-on futó, sok giga rammal rendelkező, nagyfelbontású nanoszámítógépek vannak a zsebünkben. Oldja meg a gép.

A backendek olyankor bonyolódnak, ha nagy a terhelés, vagy valamiért nyers prociból nem tudjuk kiszolgálni a sebességet - máskor meg a "validáld, hogy jó adatot kapsz-e, majd rakd el storage-ba, és köpd vissza ha kérik" szintűek.

Nincs egyértelmű válasz.

( hardhead | 2015. 08. 23., v – 02:06 )

Ha már itt tartunk: Van valami praktikus oka annak, hogy webes fejlesztéseknél a backend is webes? (Szerintem biztonsági kockázat.) Ez így alakult történelmileg, vagy így ugyanazok fejleszthetik akik a frontend-et is, vagy van egy kifejezett praktikus oka, amiről "lemaradtam"?

Van amikor a "backend" (az adminfelület, itt nem ezt értjük backenden) desktop, de azok a kényelmi okok, amik kiszorították a desktop szoftvereket (bárhonnan használható, nem kell telepíteni, nincs nagy kompatibilitási zűr stb) a CMS-ekre is igazak voltak.

Én még találkoztam win32-only webshop adminnal, meg iWeb meg hasonló desktop CMS-ekkel, és nyilván sokszor a desktopon futó számlázó, raktárkezelő, ERP vagy egyéb cucc menedzseli a weboldalt vagy annak egy részét.

Sőt, a FIBA versenyszervező szoftverei is desktopon futnak (mert nem tuti hogy lesz net), és élőben update-elik a weboldalt (ha mégis van).

( broven | 2015. 08. 23., v – 09:25 )

Ha ilyen egyszerű lenne az élet, hogy backend meg frontend... :P

( asusu | 2015. 08. 23., v – 13:56 )

Ha az átlagos projekt mondjuk egy blog szintü dolog, client-side renedereléssel, akkor frontendet nehezebb fejleszteni, és nem tudom, hogy könnyebb-e találni, mert nálunk mindenki fullstack dev.

( uid_17720 | 2015. 08. 23., v – 21:00 )

Mit kell nyomni akkor, ha fejlesztek, ráadásul csapatban, viszont nincsenek full stack developerek a többi válaszlehetőség pedig nem felel meg számomra?

( BeniBoy | 2015. 08. 23., v – 22:36 )

Van ennek a kérdésnek egy olyan vetülete is, ami manapság nem nyilvánvalóan meghatározható, szerintem a frontend-ben is két féle ember létezhet:

- egy aki a HTML/CSS dolgokkal törődik
- illetve egy másik aki az alkalmazás logikát írja (angularjs és társai)

Mert ugye a frontend és a backend nem mindig jelent azonos kódbázist (pl REST API/JSON-RPC és angularjs frontend).

És ilyenkor azért nagyon nem mindegy hogy milyen frontendest értünk. Nekem például olyan projektem van, ahol a backendet más fejlesztő csapat fejleszi, mint a frontendet (más kontinensen!). Plusz az idő is sürget, ilyen esetben a frontendnél is hatalmas erőforrásokat kell belefektetni a fejlesztésbe, hogy minden klappoljon. De ugyanez igaz a backendre is.