È comune separare back-end e front-end in due posizioni in progetti di sviluppo web?

In una startup web, è più comune avere un ingegnere che lavora sul front-end E sul back-end della funzione (sostanzialmente responsabile dell'intera funzionalità)? Oppure gli ingegneri si sono separati tra il back-end e il front-end?

Quali sono più utili e per quali situazioni?

Il rovescio della medaglia, ho notato, riguardo all'avere un ingegnere responsabile dell'intera funzionalità è che la persona potrebbe essere particolarmente forte nello sviluppo di frontend o backend, ma non in entrambi, a volte con una diminuzione della velocità e della qualità.

Avere sviluppatori frontend e backend su una funzionalità aumenta la velocità della funzionalità e la qualità E incoraggia la collaborazione. Ma sono preoccupato per il fatto che 2 ingegneri lavorino su una caratteristica che potrebbe essere un cattivo uso delle risorse poiché il 1 ingegnere può essere posizionato su un'altra funzione su cui lavorare.

Qual è la pratica comune / migliore per l'allocazione delle risorse di ingegneria backend / frontend in una piccola fase iniziale? E poi come cambierà man mano che cresce?

Ecco la mia saggezza da 14 anni di esperienza:

• se hai una startup, non assegnare ruoli. Spero meglio che tu abbia riunito una buona squadra auto-organizzata. Se tutti si conoscono, tutti sanno chi fa il meglio. Un project manager sarà solo di ostacolo.
• più tardi, la distinzione tra front-end e back-end ha un senso. Nel backend, la qualità è prio. Il codice deve essere performante, sicuro e sicuro per le transazioni. Nel front-end, i tempi di implementazione sono importanti. E devi essere in grado di fare affidamento su un buon back-end. I diversi obiettivi di front-end e back-end non funzionano bene insieme.
• il back-end dovrebbe già esistere prima che il coder front-end inizi a funzionare. Altrimenti, il codificatore front-end verrà rallentato troppo.
• il backend deve essere in grado di reagire rapidamente ai requisiti del front-end al fine di non rallentarli

La migliore risposta è di @Shark, ma solo l'ultima parte "Dipende". Nella mia esperienza, circa 16 anni circa, ho visto entrambe le opzioni tentate in una varietà di configurazioni diverse. Essendo anch'io uno sviluppatore full stack, ecco cosa ho imparato:

* (BE = back-end, FE = front-end)

Avvertenze generali sullo sviluppo dello stack diviso:

1. Le pratiche di sviluppo agili (una strategia comune in questi giorni) raccomandano lo sviluppo di funzionalità, in cui la funzionalità è un singolo prezioso pezzo di funzionalità dal punto di vista del cliente. Da questo punto di vista dovresti avere il tuo sviluppatore implementare entrambi.

2. Dividere lo stack lungo il confine del server crea un punto di integrazione tra i due sviluppatori. A meno che non comunichino efficacemente e funzionino bene insieme, ciò causerà un discreto numero di bug quando le due caratteristiche si uniranno.

3. Applica la regola di comunicazione n (n-1) / 2 dal Mese Man-Month e vedrai che dividere le funzioni in due parti tra due persone aumenterà il tuo carico di lavoro complessivo. È vero che questa regola si applica anche alle funzionalità, ma la divisione dello stack raddoppia la quantità di comunicazione.

4. Un designer risolverà i problemi degli sviluppatori BE che non sono in grado di produrre da zero interfacce interessanti. Ciò presuppone che almeno conoscano html e css e possano produrre un'interfaccia che corrisponda agli screenshot creati dal designer.

5. Le funzioni sono in genere componenti isolati che interagiscono molto poco con altre funzionalità. Questo non è sempre il caso, ma di solito il punto di interazione è a un livello basso come un database o un filesystem. Quindi non c'è molto da impedire a uno sviluppatore full-stack di implementare la propria funzionalità. Ma se uno sviluppatore FE deve attendere che uno sviluppatore BE finisca un'attività, aggiungerà un ulteriore ritardo oltre alla perdita di produttività al punto 3.

6. Web 2.0 sfuma ulteriormente la distinzione tra FE e BE. Con i framework MVC e le intere applicazioni costruite sul lato client, è necessaria una buona conoscenza di BE per implementare applicazioni FE sicure ed efficienti.

7. La mia più grande lamentela nei confronti di questa pratica è che limita le capacità di tutti i soggetti coinvolti nel progetto. Sebbene questa fosse una pratica comune nei primi anni del 2000, è stata fatta per necessità perché trovare sviluppatori che potevano fare entrambe le cose era piuttosto difficile (puramente a causa della novità non a causa di una difficoltà intrinseca nell'apprendimento di entrambi.) Ciò che rimane della pratica è un decennio dopo abbiamo ancora "sviluppatori web" che non conoscono i CSS.

8. La mia seconda lamentela più grande è che può facilmente segmentare un team di sviluppo. Uno sviluppatore FE crea un bug dopo aver modificato il codice BE e il team vota per limitare lo sviluppo cross-stack all'ingrosso. Mentre la revisione del codice e l'educazione potrebbero risolvere il problema, le persone diventano invece territoriali.

Vantaggi / Casi d'uso dello sviluppo di stack divisi:

1. Le API RESTful sono perfette per questa delineazione perché non esiste FE. Spesso un'azienda lavorerà prima su un'API RESTful, quindi svilupperà le proprie applicazioni web in cima. In questo caso esiste un valido motivo per mantenere il team BE focalizzato sulla prossima versione principale mentre la FE sta finendo l'applicazione. Ma esiste ancora il pericolo di abbandono, soprattutto se le nuove informazioni scoperte nella fase di sviluppo FE richiedono modifiche non banali all'API BE.

2. Anche i carichi di lavoro sbilanciati tra FE e BE sono un buon esempio per la creazione di un team solo FE. Anche in questo caso è molto situazionale in cui forse lo sviluppo principale viene effettuato tramite un'applicazione desktop e la società sta cercando di sviluppare un'interfaccia web "lite".

3. Formazione di sviluppatori nuovi / junior. Se stai assumendo un tirocinante o uno sviluppatore junior e sei preoccupato di buttarli nel deepend, è una buona opzione investire un po 'di quei costi di comunicazione / integrazione in un sistema di sviluppo tra pari.

Preoccupazioni per la risposta accettata da @ Ralf in questa pagina:

1. Il primo punto è piuttosto audace e fallirà rapidamente se non si dispone di una di quelle "buone squadre auto-organizzanti". Anche se hai quella squadra, è nel tuo e nei loro interessi spingere i loro confini. E i buoni team auto-organizzati non sono sempre auto-motivati ​​a farlo.

2. Il tuo secondo punto è semplicemente sbagliato. Lo sviluppo web moderno richiede un codice FE che sia performante, sicuro, asincrono sicuro, a prova di XSS, cross-browser e sviluppato rapidamente. Gli obiettivi semplicemente non competono con BE, sono effettivamente uguali.

3. Anche il terzo punto è un cattivo presupposto: lo sviluppo della FE può iniziare con puro html / css / js senza alcun lavoro di fondazione BE. Da lì è solo uno sforzo banale scomporlo in modelli per il rendering BE. Spesso è meglio iniziare con il lavoro FE perché darà alle parti interessate una sensazione calda e confusa di vedere i progressi visivi in ​​anticipo.

Conclusione:

Se sei una startup e non hai molto tempo o denaro da perdere, non assumere solo sviluppatori FE o BE. Assumi sviluppatori web di alto livello e un buon ux / designer e faranno decollare la tua applicazione il più rapidamente possibile. Costano di più, ma sono molto più produttivi e ne avrai bisogno di meno.

Penso che la domanda sia sbagliata.

Tutte le startup a cui ho preso parte non avevano solo un'architettura FE-BE.

La maggior parte delle startup che conosco hanno:

• Core: il prodotto reale che espone un'interfaccia
• UI - BE e FE. BE utilizza l'API del Core.

Le API sono apolidi e facilmente derise, anche senza la necessità di uno sviluppatore principale. Inferno, se dovessi iniziare un progetto da zero, potrei iniziare con un'intera interfaccia utente che funziona esclusivamente su simulazioni - che sarà eccezionale per le presentazioni. Gran parte del feedback è dovuto all'interfaccia utente. I clienti notano che altro - (dipende dal tuo pubblico di destinazione.)

Ad esempio: Ricerca Google ha il componente Core che esegue la scansione del Web, lo indicizza ecc. E l'interfaccia utente di Google è un mondo completamente diverso. Questo core può facilmente supportare ricerche non sul WWW, mentre l'interfaccia utente no.

In questo modo la tua interfaccia utente è "innestabile" e hai la separazione delle preoccupazioni.

Hai fatto riferimento alla conoscenza dello sviluppo, ma stai trascurando gli aspetti della gestione del progetto. Mentre il core team potrebbe aver bisogno di una durata dello sprint di 2 settimane, il team dell'interfaccia utente utilizzerà CI: tutto viene caricato continuamente. Il team principale avrà bisogno di compatibilità con le versioni precedenti, mentre l'interfaccia utente no.

La lingua è diversa. Probabilmente avrai bisogno di sviluppatori C per il componente Core e andrai bene se viene eseguito su un singolo sistema operativo, dove l'interfaccia utente verrà scritta in un linguaggio Cross OS.

I test differiscono. Il mondo dei test dell'interfaccia utente è uno dei più complessi che conosco nello sviluppo di software. La maggior parte delle startup lo trascura e rimpiange questa decisione in seguito. Non è possibile separare BE e FE durante il test. Deve essere una singola unità che la gestisce.

Interfaccia utente open source: uno dei maggiori vantaggi della separazione dei due è la possibilità di open source l'interfaccia utente. Il progetto UI necessita di supporto open source.

Non riesco a immaginare uno sviluppatore dell'interfaccia utente in grado di comprendere l' intera session funzionalità. Sai - dove accedi e rimani connesso tra diverse richieste. È vero che potrebbero conoscere PHP e non Java .. ma il concetto di BE dovrebbe essere chiaro (ad es. Utilizzare un cookie crittografato). La barriera linguistica specifica è errata: ogni sviluppatore dovrebbe essere disposto a lavorare in qualsiasi lingua. Chi avrebbe mai pensato che avrebbero scritto BE in JavaScript un paio di anni fa?

Se continui ad avere 3 squadre: Core, BE e FE, è uno spreco di risorse imho. Che mi dici di DB? dovresti avere DBA? Perché uno sviluppatore BE dovrebbe conoscere DB e uno sviluppatore FE non conoscere BE e DB? Non c'è limite.

Se hai bisogno di esperti e lo farai, l'outsourcing di questi funziona abbastanza bene. Generalmente forniscono un codice di qualità e lo fanno abbastanza velocemente. Non li vuoi necessariamente internamente perché ti perderai se se ne vanno. Inoltre puoi ricevere ottimi consigli online oggi. Roba all'avanguardia potrebbe richiedere un approccio diverso.

Quindi il risultato è sostanzialmente un BE molto sottile nell'interfaccia utente che ogni sviluppatore FE può sviluppare. Se hai un grosso BE nell'interfaccia utente, molto probabilmente hai alcune funzionalità API richieste nel Core.

C'è sempre almeno uno sviluppatore che si distingue dal resto. Dato un FE così sottile, può gestire fornendo (non sviluppando) altri sviluppatori nel codice BE. La mia opinione è che questo sviluppatore è in una posizione molto buona e dovrebbe essere assegnato in modo appropriato (non in stipendio però, qualcos'altro). Confido inoltre che saranno in grado di gestire il processo di compilazione e la compilazione in modo corretto.

Questo modello offre una grande flessibilità per quanto riguarda lo sviluppo di BE. Il mondo BE ha conosciuto diversi cambiamenti negli ultimi due anni, quindi non raccomando di fare troppo affidamento sulla stabilità BE. Core è una storia diversa.

Rimane ancora la domanda: FE e BE dovrebbero essere lo stesso progetto ? Si dovrebbe notare quanto segue

• Le risorse statiche vengono gestite al meglio dal front-server. Poiché i server front-end (ad esempio nginx) sono molto potenti e poiché è possibile utilizzare la cache per risorse statiche, è possibile gestire con una singola distribuzione delle risorse statiche (che dovrebbe essere tutto il contenuto HTML, JS, CSS, Immagini).
• Il codice back-end non ha gli stessi lussi, quindi è necessario disporre di un sistema distribuito, che è anche gestito da un front-server.
• Il codice FE deve essere riutilizzato con tutte le nuove tecnologie che supportano JavaScript. Ora puoi scrivere applicazioni desktop e mobili con JavaScript.
• Il processo di compilazione è completamente diverso e può includere anche la consegna, l'aggiornamento, l'installazione delle patch, ecc.

Posso continuare, ma spero sia chiaro che penso che BE e FE debbano essere la stessa squadra, ma forse progetti diversi.

Penso che l'implementazione di successo potrebbe essere alcune cose. Se esiste un solo sviluppatore che ha un forte back-end ma ha anche una buona conoscenza dell'interfaccia utente e di tutti i pezzi "front-end", probabilmente potrebbe avere successo. Questo non è in genere il caso, tuttavia (nella mia esperienza personale). Ad esempio, mi considero uno sviluppatore back-end. Ma lavoro su molti progetti da solo. Lavoro sulla presentazione e sui pezzi lato client? Sicuro. Sembrano belli come farebbe un vero designer di talento e uno sviluppatore lato client? Assolutamente no.

È tutto dare e avere. Ma non lasciare che la collaborazione di due sviluppatori ti esiti. Ci sono modi provati e veri per massimizzare la produzione tra uno sviluppatore e un designer.

In altre parole ... dipende