É comum separar back-end e front-end em duas posições em projetos de desenvolvimento web?

Em uma inicialização na web, é mais comum ter um engenheiro trabalhando no front end e back-end do recurso (basicamente responsável por todo o recurso)? Ou os engenheiros se separaram entre o back-end e o front-end?

Quais são mais benéficos e para quais situações?

A desvantagem, notei, em relação a ter um engenheiro responsável por todo o recurso é que a pessoa pode ser particularmente forte no desenvolvimento de front-end ou back-end, mas não em ambos, portanto, às vezes, diminuindo a velocidade e a qualidade.

Ter desenvolvedores de front-end e back-end em um recurso aumenta a velocidade do recurso e a qualidade E incentiva a colaboração. Mas estou preocupado em ter 2 engenheiros trabalhando em um recurso, o que pode ser um uso insuficiente de recursos, pois o engenheiro 1 pode ser colocado em outro recurso para trabalhar.

Qual é a prática comum / melhor prática para alocar recursos de engenharia de back-end / front-end em uma pequena inicialização no estágio inicial? E então como vai mudar à medida que cresce?

Aqui está a minha sabedoria de 14 anos de experiência:

• se você tiver uma inicialização, não atribua funções. Espero que você tenha reunido uma boa equipe de auto-organização. Se todo mundo se conhece, todo mundo sabe quem faz o que é melhor. Um gerente de projeto ficará apenas no caminho.
• mais tarde, a distinção entre front-end e back-end faz sentido. No back-end, a qualidade é o primeiro. O código deve ter desempenho, segurança e segurança de transação. No front-end, o tempo de implementação é importante. E você deve poder confiar em um bom back-end. Os diferentes objetivos do front-end e back-end não funcionam bem juntos.
• o back-end já deve existir antes que o codificador do front-end comece a funcionar. Caso contrário, o codificador front-end ficará muito lento.
• o back-end deve ser capaz de reagir rapidamente aos requisitos de front-end para não atrasá-los

A melhor resposta é do @Shark, mas apenas a última parte "Depende". Na minha experiência, ~ 16 anos ou mais, eu vi as duas opções tentadas em uma variedade de configurações diferentes. Sendo um desenvolvedor de pilha cheia, eis o que eu aprendi:

* (BE = Back End, FE = Front End)

Advertências gerais sobre desenvolvimento de pilha dividida:

1. As práticas de desenvolvimento ágil (uma estratégia comum hoje em dia) recomendam o desenvolvimento de recursos, em que o recurso é uma única peça valiosa de funcionalidade da perspectiva do cliente. Nessa perspectiva, seu desenvolvedor deve implementar ambos.

2. Dividir a pilha ao longo do limite do servidor cria um ponto de integração entre os dois desenvolvedores. A menos que eles se comuniquem efetivamente e trabalhem bem juntos, isso causará um número razoável de bugs quando os dois recursos se unirem.

3. Aplique a regra de comunicação n (n-1) / 2 do Mythical Man-Month e você verá que a divisão de recursos em duas partes entre duas pessoas aumentará sua carga de trabalho geral. Essa regra também se aplica aos recursos, mas dividir a pilha dobra a quantidade de comunicação.

4. Um designer resolverá os problemas dos desenvolvedores do BE que não conseguem produzir interfaces atraentes a partir do zero. Isso pressupõe que eles pelo menos conhecem html & css e podem produzir uma interface que corresponda às capturas de tela criadas pelo designer.

5. Recursos geralmente são componentes isolados que interagem muito pouco com outros recursos. Nem sempre é esse o caso, mas geralmente o ponto de interação está em um nível baixo, como um banco de dados ou sistema de arquivos. Portanto, não há muito impedindo que um desenvolvedor de pilha cheia implemente seu recurso. Mas se um desenvolvedor de EF precisar esperar que um desenvolvedor de BE conclua uma tarefa, ele adicionará ainda mais atraso além da perda de produtividade no ponto 3.

6. Web2.0 obscurece ainda mais a distinção entre FE & BE. Com estruturas MVC e aplicativos inteiros sendo construídos no lado do cliente, agora é necessário muito conhecimento de BE para implementar aplicativos de EF seguros e eficientes.

7. Minha maior reclamação por essa prática é que ela limita as habilidades de todos os envolvidos no projeto. Embora essa fosse uma prática comum no início dos anos 2000, isso foi feito por necessidade, porque encontrar desenvolvedores que pudessem fazer as duas coisas era bastante difícil (puramente por causa da novidade, não por causa de alguma dificuldade intrínseca em aprender as duas coisas.) O que resta da prática é uma década depois, ainda temos "desenvolvedores da web" que não conhecem CSS.

8. Minha segunda maior reclamação é que ela pode segmentar facilmente uma equipe de desenvolvimento. Um desenvolvedor de FE cria um bug após modificar o código BE e a equipe vota para restringir o desenvolvimento de pilha cruzada no atacado. Enquanto a revisão de códigos e a educação podem resolver o problema, as pessoas se tornam territoriais.

Benefícios / casos de uso do desenvolvimento de pilha dividida:

1. As APIs RESTful são perfeitas para esse delineamento porque não há FE. Freqüentemente, uma empresa trabalha primeiro em uma API RESTful e depois desenvolve seus aplicativos Web no topo. Nesse caso, existe um forte argumento para manter a equipe do BE focada na próxima versão principal enquanto o EF está finalizando o aplicativo. Mas o perigo de rotatividade ainda existe - especialmente se novas informações descobertas na fase de desenvolvimento da FE exigirem modificações não triviais na API do BE.

2. Cargas de trabalho desequilibradas entre a FE & BE também são um bom exemplo para a criação de uma equipe exclusiva da FE. Novamente, isso é muito situacional, onde talvez o principal desenvolvimento seja feito por meio de um aplicativo de desktop e a empresa esteja tentando desenvolver uma interface da Web 'leve'.

3. Treinamento de desenvolvedores novos / juniores. Se você está contratando um estagiário ou um desenvolvedor júnior e está preocupado em jogá-los no deepend, é uma boa opção investir parte desse custo de comunicação / integração em um sistema de desenvolvimento por pares.

Preocupações com a resposta aceita por @ Ralf nesta página:

1. O primeiro ponto é bastante ousado - e falhará rapidamente se você não tiver uma dessas "boas equipes de auto-organização". Mesmo se você tiver essa equipe, é do seu interesse e dos deles ultrapassar seus limites. E boas equipes auto-organizadas nem sempre são motivadas para isso.

2. Seu segundo ponto está errado. O desenvolvimento moderno da Web requer um código FE com desempenho, segurança, segurança assíncrona, à prova de XSS, navegador cruzado e desenvolvido rapidamente. Os objetivos simplesmente não competem com o BE, eles são efetivamente iguais.

3. O terceiro ponto também é uma suposição ruim - o desenvolvimento de FE pode começar com html / css / js puro, sem qualquer trabalho de fundação do BE. A partir daí, é apenas um esforço trivial dividi-lo em modelos para renderização BE. Muitas vezes, é melhor começar com o trabalho de EF, pois dará às partes interessadas uma sensação acolhedora e confusa de ver o progresso visual antecipadamente.

Conclusão:

Se você é uma startup e não tem muito tempo ou dinheiro para gastar, não contrate desenvolvedores de FE ou BE apenas. Contrate desenvolvedores web de nível sênior e um bom designer / ux, e eles tirarão seu aplicativo do papel o mais rápido possível. Eles custam mais, mas são muito mais produtivos e você precisará de menos deles.

Eu acho que a pergunta está errada.

Todas as startups em que participei não tinham uma arquitetura única FE-BE.

A maioria das startups que conheço tem:

• Principal - o produto real que expõe uma interface
• UI - BE e FE. O BE usa a API do núcleo.

As APIs são apátridas e facilmente zombadas - mesmo sem a necessidade de um desenvolvedor principal. Inferno, se eu tivesse que iniciar um projeto do zero, poderia começar com uma interface do usuário inteira que funcionasse apenas com zombarias - o que será ótimo para apresentações. A maior parte do feedback é devido à interface do usuário. Os clientes observam que mais - (depende do seu público-alvo).

Por exemplo - a Pesquisa do Google tem o componente Principal que rastreia a web, indexa-o etc. A interface do usuário do Google é um mundo totalmente diferente. Esse núcleo pode suportar facilmente pesquisas que não são da WWW, enquanto a interface do usuário não.

Dessa forma, sua interface do usuário é "conectável" e você tem uma separação de preocupações.

Você se referiu ao conhecimento de desenvolvimento, mas está negligenciando os aspectos de gerenciamento de projetos. Embora a equipe principal possa precisar de duas semanas de duração do sprint, a equipe da interface do usuário usará o IC - tudo é carregado o tempo todo. A equipe principal precisará de compatibilidade com versões anteriores, enquanto a interface do usuário não.

O idioma é diferente. Você provavelmente desejará desenvolvedores C para o componente Core - e ficará bem se for executado em um único sistema operacional, onde a interface do usuário será gravada em uma linguagem Cross OS.

Os testes diferem. O mundo dos testes de interface do usuário é um dos mais complexos que conheço no desenvolvimento de software. A maioria das startups a negligencia e se arrepende dessa decisão posteriormente. Você não pode separar BE e FE durante o teste. Tem que ser uma única unidade que lide com isso.

Interface do usuário de código aberto - um dos maiores benefícios da separação dos dois é que você pode abrir a interface do usuário de código-fonte aberto. O projeto de interface do usuário precisa de suporte de código aberto.

Não consigo imaginar um desenvolvedor de interface do usuário que não entenda todo o session recurso. Você sabe - onde você faz login e permanece conectado entre diferentes solicitações. É verdade que eles podem conhecer PHP e não Java .. mas o conceito BE deve ser claro (por exemplo, use um cookie criptografado). A barreira específica do idioma está errada - todo desenvolvedor deve estar disposto a trabalhar em qualquer idioma. Quem pensaria que escreveria BE em JavaScript alguns anos atrás?

Se você continuar com três equipes: Core, BE e FE, será um desperdício de recursos. E o DB? você deveria ter DBAs? Por que um desenvolvedor de BE conhece DB e um desenvolvedor de FE não conhece BE e DB? Não há limite.

Se você precisar de especialistas, e precisará, terceirizá-los funciona muito bem. Eles geralmente entregam código de qualidade e o fazem muito rápido. Você não necessariamente os quer internamente, porque se perderá se eles forem embora. Além disso, você pode obter ótimos conselhos on-line hoje. Material de ponta pode exigir uma abordagem diferente.

Portanto, o resultado é basicamente um BE muito fino na interface do usuário que todo desenvolvedor de EF pode desenvolver. Se você tem um BE espesso na interface do usuário, provavelmente possui algumas funcionalidades de API necessárias no Core.

Sempre há pelo menos um desenvolvedor que se destaca dos demais. Dado um FE tão fino, ele pode gerenciar dando suporte (não desenvolver) outros desenvolvedores no código BE. Minha opinião é que esse desenvolvedor está em uma posição muito boa e deve ser concedido adequadamente (embora não seja o salário, outra coisa). Também confio que eles serão capazes de lidar com o processo de compilação e compilar corretamente.

Este modelo oferece uma grande flexibilidade em relação ao desenvolvimento do BE. O mundo do BE sofreu várias reviravoltas nos últimos dois anos, por isso não recomendo confiar demais na estabilidade do BE. O núcleo é uma história diferente.

Ainda resta a pergunta - FE e BE devem ser o mesmo projeto ? Você deve observar o seguinte

• Os recursos estáticos são mais bem servidos no servidor frontal. Como os servidores Front-End (por exemplo, nginx) são muito poderosos e como você pode usar o Cache para recursos estáticos, é possível gerenciar com uma única implantação dos seus recursos estáticos (que devem ser todo o conteúdo HTML, JS, CSS, Imagens).
• O código de back-end não possui os mesmos luxos; portanto, você deve ter um sistema distribuído - que também é gerenciado por um servidor front-end.
• O código FE deve ser reutilizado com todas as novas tecnologias que suportam JavaScript. Agora você pode escrever aplicativos para desktop e dispositivos móveis com JavaScript.
• O processo de compilação é completamente diferente - e pode até incluir entrega, atualização, instalação de patches etc.

Posso continuar, mas espero que fique claro que BE e FE devem ser a mesma equipe, mas talvez projetos diferentes.

Eu acho que a implementação bem-sucedida pode ser algumas coisas. Se houver um desenvolvedor único que possua um back-end forte, mas também tenha uma compreensão decente da interface do usuário e de todas as partes "front-end", provavelmente será bem-sucedido. Normalmente, esse não é o caso (na minha experiência pessoal). Por exemplo, eu me considero um desenvolvedor de back-end. Mas eu trabalho em muitos projetos sozinha. Eu trabalho na apresentação e nas peças do lado do cliente? Certo. Eles parecem tão bons quanto um designer talentoso e um desenvolvedor do lado do cliente seriam? Absolutamente não.

É tudo dar e receber. Mas não deixe a colaboração de dois desenvolvedores fazer você hesitar. Existem maneiras experimentadas e verdadeiras de maximizar a produção entre um desenvolvedor e um designer.

Em outras palavras ... Depende