¿Es común separar back-end y front-end en dos posiciones en proyectos de desarrollo web?

En un inicio web, ¿es más común tener un ingeniero trabajando en el front-end Y el back-end de la función (básicamente a cargo de toda la función)? ¿O los ingenieros se han separado entre el back-end y el front-end?

¿Cuáles son más beneficiosas y para qué situaciones?

La desventaja, noté, con respecto a tener un ingeniero a cargo de toda la función es que la persona solo puede ser particularmente fuerte en el desarrollo frontend o backend, pero no en ambos, por lo que a veces tiene una disminución en la velocidad y la calidad.

Tener desarrolladores frontend y backend en una característica aumenta la velocidad de la característica y la calidad Y fomenta la colaboración. Pero me preocupa tener 2 ingenieros trabajando en una función, lo que puede ser un mal uso de los recursos, ya que el 1 ingeniero puede ser ubicado en otra función para trabajar.

¿Cuál es la práctica común / mejor para la asignación de recursos de ingeniería backend / frontend en una pequeña startup en etapa inicial? Y entonces, ¿cómo va a cambiar a medida que crece?

Aquí está mi sabiduría de 14 años de experiencia:

• Si tiene una startup, no asigne roles. Mejor espero que hayas formado un buen equipo de autoorganización. Si todos se conocen, todos saben quién hace lo mejor. Un gerente de proyecto solo se interpondrá en el camino.
• más adelante, la distinción entre front-end y back-end tiene sentido. En el backend, la calidad es primordial. El código debe ser eficaz, seguro y seguro para las transacciones. En el front-end, el tiempo de implementación es importante. Y debe poder confiar en un buen back-end. Los diferentes objetivos de front-end y back-end no funcionan bien juntos.
• el back-end ya debería existir antes de que el codificador de front-end comience a funcionar. De lo contrario, el codificador frontal se ralentizará demasiado.
• El backend tiene que poder reaccionar rápidamente en los requisitos de front-end para no ralentizar

La mejor respuesta es de @Shark, pero solo la última parte "Depende". En mi experiencia, ~ 16 años más o menos, he visto ambas opciones intentadas en una variedad de configuraciones diferentes. Siendo un desarrollador full stack, esto es lo que he aprendido:

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

Advertencias generales del desarrollo de pila dividida:

1. Las prácticas de desarrollo ágil (una estrategia común en estos días) recomiendan el desarrollo de características, donde la característica es un solo valioso conjunto de funcionalidades desde la perspectiva del cliente. Desde esta perspectiva, debe hacer que su desarrollador implemente ambos.

2. Dividir la pila a lo largo del límite del servidor crea un punto de integración entre los dos desarrolladores. A menos que se comuniquen de manera efectiva y funcionen bien juntos, esto causará una buena cantidad de errores cuando las dos características se unan.

3. Aplique la regla de comunicación n (n-1) / 2 del Mythical Man-Month y verá que dividir las características en dos partes entre dos personas aumentará su carga de trabajo general. De acuerdo, esa regla también se aplica a las características, pero dividir la pila duplica la cantidad de comunicación.

4. Un diseñador resolverá los problemas de que los desarrolladores de BE no puedan producir interfaces atractivas desde cero. Esto supone que al menos conocen html y css y pueden producir una interfaz que coincida con las capturas de pantalla creadas por el diseñador.

5. Las características suelen ser componentes aislados que interactúan muy poco con otras características. Este no es siempre el caso, pero generalmente el punto de interacción está en un nivel bajo, como una base de datos o un sistema de archivos. Por lo tanto, no hay mucho que impida que un desarrollador de pila completa implemente su función. Pero si un desarrollador de FE tiene que esperar a que un desarrollador de BE finalice una tarea, agregará aún más retraso además de la pérdida de productividad en el punto 3.

6. Web2.0 borra aún más la distinción entre FE y BE. Con los marcos MVC y las aplicaciones completas que se están construyendo en el lado del cliente, ahora se requiere una gran cantidad de conocimiento BE para implementar aplicaciones FE seguras y eficientes.

7. Mi mayor queja sobre esta práctica es que limita las habilidades de todos los involucrados en el proyecto. Aunque esta era una práctica común a principios de la década de 2000, se hizo por necesidad porque encontrar desarrolladores que pudieran hacer ambas cosas era bastante difícil (simplemente por la novedad, no por alguna dificultad intrínseca para aprender ambas). Lo que queda de la práctica es una década después todavía tenemos "desarrolladores web" que no conocen CSS.

8. Mi segunda mayor queja es que puede segmentar fácilmente un equipo de desarrollo. Un desarrollador de FE crea un error después de modificar el código BE y el equipo vota para restringir el desarrollo cross-stack al por mayor. Mientras que las revisiones de códigos y la educación podrían resolver el problema, las personas se vuelven territoriales.

Beneficios / casos de uso del desarrollo de pila dividida:

1. Las API RESTful son perfectas para esta delineación porque no hay FE. A menudo, una empresa trabajará primero en una API RESTful y luego desarrollará sus aplicaciones web en la parte superior. En este caso, existe un fuerte argumento para mantener al equipo de BE enfocado en la próxima versión principal mientras la FE finaliza la aplicación. Pero el peligro de abandono aún existe, especialmente si la nueva información descubierta en la fase de desarrollo de FE requiere modificaciones no triviales a la API BE.

2. Las cargas de trabajo desequilibradas entre FE y BE también son un buen caso para crear un equipo de solo FE. Nuevamente, esto es muy situacional, donde quizás el desarrollo principal se realiza a través de una aplicación de escritorio y la compañía está tratando de desarrollar una interfaz web 'lite'.

3. Capacitación de desarrolladores nuevos / junior. Si está contratando a un pasante o un desarrollador junior y le preocupa arrojarlos a la profundidad, es una buena opción invertir parte de ese costo de comunicación / integración en un sistema de desarrollo de pares.

Preocupaciones sobre la respuesta aceptada de @ Ralf en esta página:

1. El primer punto es bastante audaz, y fallará rápidamente si no tiene uno de esos "buenos equipos de autoorganización". Incluso si tiene ese equipo, le interesa a usted y a sus intereses ampliar sus límites. Y los buenos equipos autoorganizados no siempre están motivados para hacerlo.

2. Tu segundo punto es simplemente incorrecto. El desarrollo web moderno requiere un código FE que sea eficaz, seguro, asincrónico, a prueba de XSS, de navegador cruzado y desarrollado rápidamente. Los objetivos simplemente no compiten con BE, son efectivamente iguales.

3. El tercer punto también es una mala suposición: el desarrollo de FE puede comenzar con html / css / js puro sin ningún trabajo básico de BE. A partir de ahí, solo es un esfuerzo trivial dividirlo en plantillas para renderizar BE. Muchas veces es mejor comenzar con el trabajo de FE porque les dará a las partes interesadas una sensación cálida y difusa de ver el progreso visual por adelantado.

Conclusión:

Si eres una startup y no tienes mucho tiempo o dinero para gastar, entonces no contrates desarrolladores FE o BE. Contrata desarrolladores web de alto nivel y un buen diseñador de experiencia de usuario, y harán que tu aplicación despegue lo más rápido posible. Cuestan más, pero son mucho más productivos y necesitarás menos.

Creo que la pregunta está mal.

Todas las startups en las que participé no tenían una arquitectura única FE-BE.

La mayoría de las startups que conozco tienen:

• Core: el producto real que expone una interfaz
• UI - BE y FE. El BE utiliza la API del núcleo.

Las API no tienen estado y se burlan fácilmente, incluso sin la necesidad de un desarrollador principal. Demonios, si tuviera que comenzar un proyecto desde cero, podría comenzar con una interfaz de usuario completa que funcione exclusivamente en simulacros, lo que será ideal para presentaciones. La mayoría de los comentarios se deben a la interfaz de usuario. Los clientes notan que más: (depende de su público objetivo).

Por ejemplo, Google Search tiene el componente Core que rastrea la web, lo indexa, etc. y la interfaz de usuario de Google es un mundo totalmente diferente. Este núcleo puede admitir fácilmente búsquedas no WWW, mientras que la interfaz de usuario no puede.

De esta manera, su interfaz de usuario es "conectable" y tiene una separación de preocupaciones.

Se refirió al conocimiento del desarrollo, sin embargo, pasa por alto los aspectos de gestión de proyectos. Si bien el equipo central puede necesitar 2 semanas de duración del sprint, el equipo de la IU usará CI: todo se carga todo el tiempo. El equipo Core necesitará compatibilidad con versiones anteriores, mientras que la IU no.

El idioma es diferente. Probablemente querrá desarrolladores de C para el componente Core, y estará bien si se ejecuta en un solo sistema operativo, ya que la IU se escribirá en un lenguaje de sistema operativo cruzado.

Las pruebas difieren. El mundo de prueba de IU es uno de los más complejos que conozco en el desarrollo de software. La mayoría de las startups lo descuidan y lamentan esta decisión más adelante. No puede separar BE y FE al realizar la prueba. Tiene que ser una sola unidad que lo maneje.

Interfaz de usuario de código abierto: uno de los mayores beneficios de separar los dos es que puede abrir el código de su interfaz de usuario. El proyecto de interfaz de usuario necesita soporte de código abierto.

No puedo imaginar un desarrollador de UI que no pueda entender toda la session función. Ya sabes: dónde inicias sesión y quédate conectado entre diferentes solicitudes. Es cierto que pueden conocer PHP y no Java ... pero el concepto BE debe ser claro (por ejemplo, usar una cookie encriptada). La barrera específica del idioma está mal: cada desarrollador debe estar dispuesto a trabajar en cualquier idioma. ¿Quién hubiera pensado que escribirían BE en JavaScript hace un par de años?

Si sigues teniendo 3 equipos: Core, BE y FE, es un desperdicio de recursos en mi humilde opinión. ¿Qué hay de DB? deberías tener DBA? ¿Por qué un desarrollador BE debería conocer DB y un desarrollador FE no conocer BE y DB? No hay limite.

Si necesita expertos, y lo hará, externalizarlos funciona bastante bien. Generalmente entregan código de calidad y lo hacen bastante rápido. No necesariamente los quieres en casa porque te perderás si se van. Además, puede obtener excelentes consejos en línea hoy. Cosas de vanguardia pueden requerir un enfoque diferente.

Entonces, el resultado es básicamente un BE muy delgado en la interfaz de usuario que cada desarrollador de FE puede desarrollar. Si tiene un BE grueso en la interfaz de usuario, probablemente tenga alguna funcionalidad de API requerida en el Core.

Siempre hay al menos un desarrollador que se destaca del resto. Dada una FE tan delgada, él / ella puede administrar dar soporte (no desarrollar) a otros desarrolladores en código BE. Mi opinión es que este desarrollador está en una muy buena posición y debe ser otorgado de manera apropiada (sin embargo, no en salario, otra cosa). También confío en que podrán manejar el proceso de compilación y compilar adecuadamente.

Este modelo le brinda una gran flexibilidad con respecto al desarrollo de BE. El mundo BE ha experimentado varios cambios en los últimos años, por lo que no recomiendo confiar demasiado en la estabilidad BE de todos modos. Core es una historia diferente.

Todavía queda la pregunta: ¿deberían FE y BE ser el mismo proyecto ? Debe tener en cuenta lo siguiente

• Los recursos estáticos se sirven mejor desde el servidor frontal. Dado que los servidores front-end (p. Ej., Nginx) son muy potentes y puede usar Cache para recursos estáticos, puede administrarlos con una sola implementación de sus recursos estáticos (que deben ser todo el contenido HTML, JS, CSS, imágenes).
• El código de back-end no tiene los mismos lujos, por lo que debe tener un sistema distribuido, que también es administrado por un servidor frontal.
• El código FE se debe reutilizar con todas las nuevas tecnologías que admiten JavaScript. Ahora puede escribir aplicaciones de escritorio y móviles con JavaScript.
• El proceso de compilación es completamente diferente, e incluso puede incluir entrega de parches, actualización, instalación, etc.

Puedo continuar, pero espero que quede claro que creo que BE y FE deberían ser el mismo equipo, pero quizás proyectos diferentes.

Creo que la implementación exitosa podría ser algunas cosas. Si hay un desarrollador único que tiene un backend fuerte pero también tiene una comprensión decente de la interfaz de usuario y todas las piezas "frontales", entonces probablemente podría ser exitoso. Sin embargo, ese no suele ser el caso (en mi experiencia personal). Por ejemplo, me considero un desarrollador de back-end. Pero trabajo solo en muchos proyectos. ¿Trabajo en la presentación y las piezas del lado del cliente? Seguro. ¿Se ven tan bien como un diseñador con talento real y un desarrollador del lado del cliente lo harían? Absolutamente no.

Todo es toma y daca. Pero no dejes que la colaboración de dos desarrolladores te haga dudar. Hay formas probadas y verdaderas para maximizar la producción entre un desarrollador y un diseñador.

En otras palabras ... depende