Est-il courant de séparer le back-end et le front-end en deux positions sur les projets de développement web?
Lors d'un démarrage Web, est-il plus courant qu'un ingénieur travaille le front-end ET le back-end de la fonctionnalité (essentiellement en charge de la fonctionnalité entière)? Ou les ingénieurs sont-ils séparés entre le back-end et le front-end?
Lesquelles sont les plus bénéfiques et pour quelles situations?
L'inconvénient, j'ai remarqué, d'avoir un ingénieur en charge de l'ensemble de la fonctionnalité est que la personne ne peut être particulièrement forte que dans le développement frontend ou backend mais pas les deux, ce qui entraîne parfois une diminution de la vitesse et de la qualité.
Avoir des développeurs frontend et backend sur une fonctionnalité augmente la vitesse de la fonctionnalité et la qualité ET cela encourage la collaboration. Mais je suis préoccupé par le fait que 2 ingénieurs travaillent sur une fonctionnalité, ce qui peut être une mauvaise utilisation des ressources, car 1 ingénieur peut être placé sur une autre fonctionnalité pour travailler.
Quelle est la meilleure pratique/courante pour l'allocation de ressources d'ingénierie backend/frontend dans une petite start-up en démarrage? Et comment cela va-t-il changer à mesure qu'il grandit?
Voici ma sagesse de 14 ans d'expérience:
- si vous avez une startup, n'attribuez pas de rôles. Espérons que vous avez réuni une bonne équipe auto-organisée. Si tout le monde se connaît, tout le monde sait qui fait le mieux. Un chef de projet ne fera que gêner.
- plus tard, la distinction entre front-end et back-end prend tout son sens. Dans le backend, la qualité est primordiale. Le code doit être performant, sécurisé et sécurisé pour les transactions. Dans le front-end, le temps de mise en œuvre compte. Et vous devez pouvoir compter sur un bon back-end. Les différents objectifs du front et du back-end ne fonctionnent pas bien ensemble.
- le back-end doit déjà exister avant que le codeur frontal ne commence à fonctionner. Sinon, le codeur frontal sera trop ralenti.
- le backend doit être capable de réagir rapidement aux exigences du front-end afin de ne pas les ralentir
La meilleure réponse vient de @Shark, mais seulement de la dernière partie "Cela dépend". D'après mon expérience, environ 16 ans, j'ai vu les deux options tentées dans une variété de configurations différentes. Étant moi-même un développeur de pile complète, voici ce que j'ai appris:
* (BE = Back End, FE = Front End)
Avertissements généraux sur le développement de la pile fractionnée:
Les pratiques de développement agile (une stratégie courante ces jours-ci) recommandent le développement de fonctionnalités, où la fonctionnalité est un ensemble de fonctionnalités précieux du point de vue du client. Dans cette perspective, votre développeur devrait implémenter les deux.
La division de la pile le long de la frontière du serveur crée un point d'intégration entre les deux développeurs. À moins qu'ils ne communiquent efficacement et fonctionnent bien ensemble, cela entraînera un bon nombre de bogues lorsque les deux fonctionnalités se rejoignent.
Appliquez la règle de communication n (n-1)/2 du Mythical Man-Month et vous verrez que le fractionnement des fonctionnalités en deux parties entre deux personnes augmentera votre charge de travail globale. Certes, cette règle s'applique également aux fonctionnalités, mais le fractionnement de la pile double la quantité de communication.
Un concepteur résoudra les problèmes des développeurs BE ne pouvant pas produire des interfaces attrayantes à partir de zéro. Cela suppose qu'ils connaissent au moins html et css et peuvent produire une interface qui correspond aux captures d'écran créées par le concepteur.
Les fonctionnalités sont généralement des composants isolés qui interagissent très peu avec d'autres fonctionnalités. Ce n'est pas toujours le cas mais généralement le point d'interaction se situe à un niveau bas comme une base de données ou un système de fichiers. Il n'y a donc pas grand-chose qui empêche un développeur à pile complète d'implémenter sa fonctionnalité. Mais si un développeur FE doit attendre un développeur BE pour terminer une tâche, cela ajoutera encore plus de retard en plus de la perte de productivité au point 3.
Web2.0 brouille encore plus la distinction entre FE et BE. Avec les frameworks MVC et des applications entières en cours de construction côté client, une bonne partie des connaissances BE est désormais requise pour implémenter des applications FE sécurisées et efficaces.
Mon plus grand reproche envers cette pratique est qu'elle limite les capacités de toutes les personnes impliquées dans le projet. Bien que ce fut une pratique courante au début des années 2000, cela a été fait par nécessité parce que trouver des développeurs qui pouvaient faire les deux était assez difficile (uniquement à cause de la nouveauté et non à cause d'une difficulté intrinsèque à apprendre les deux.) Ce qui reste de la pratique est une décennie plus tard, nous avons encore des "développeurs web" qui ne connaissent pas CSS.
Mon deuxième plus gros reproche est qu'il peut facilement segmenter une équipe de développement. Un développeur FE crée un bogue après avoir modifié le code BE et l'équipe vote pour restreindre le développement inter-piles en gros. Alors que la révision des codes et l'éducation pourraient résoudre le problème, les gens deviennent plutôt territoriaux.
Avantages/cas d'utilisation du développement de piles fractionnées:
Les API RESTful sont parfaites pour cette délimitation car il n'y a pas de FE. Souvent, une entreprise travaille d'abord sur une API RESTful, puis développe ses applications Web par-dessus. Dans ce cas, il y a de bonnes raisons de garder l'équipe BE concentrée sur la prochaine version majeure pendant que la FE termine l'application. Mais le risque de désabonnement existe toujours - surtout si de nouvelles informations découvertes dans la phase de développement FE nécessitent des modifications non triviales de l'API BE.
Les charges de travail déséquilibrées entre FE et BE sont également un bon argument pour créer une équipe FE uniquement. Encore une fois, c'est très situationnel où le développement principal est peut-être effectué via une application de bureau et la société essaie de développer une interface Web "allégée".
Formation de nouveaux développeurs/juniors. Si vous embauchez un stagiaire ou un développeur junior et que vous souhaitez les lancer dans les profondeurs, c'est une bonne option pour investir une partie de ce coût de communication/intégration dans un système de développement par les pairs.
Préoccupations concernant la réponse acceptée de @ Ralf sur cette page:
Le premier point est assez audacieux - et il échouera rapidement si vous n'avez pas une de ces "bonnes équipes auto-organisées". Même si vous avez cette équipe, il est dans votre intérêt et dans son intérêt de repousser ses limites. Et les bonnes équipes auto-organisées ne sont pas toujours motivées à le faire.
Votre deuxième point est tout simplement faux. Le développement Web moderne nécessite un code FE performant, sécurisé, asynchrone, résistant à XSS, multi-navigateur et développé rapidement. Les objectifs ne sont tout simplement pas en concurrence avec BE, ils sont effectivement égaux.
Le troisième point est également une mauvaise hypothèse - le développement FE peut commencer avec du HTML/CSS/JS pur sans aucun travail de fondation BE. De là, ce n'est qu'un effort trivial de le décomposer en modèles pour le rendu BE. Souvent, il est préférable de commencer par le travail FE car cela donnera aux parties prenantes un sentiment chaleureux et flou de voir les progrès visuels à l'avant.
Conclusion:
Si vous êtes une startup et que vous n'avez pas beaucoup de temps ou d'argent à dépenser, n'embauchez pas uniquement des développeurs FE ou BE. Embauchez des développeurs Web de haut niveau et un bon ux/designer, et ils feront démarrer votre application le plus rapidement possible. Ils coûtent plus cher, mais ils sont beaucoup plus productifs et vous en aurez besoin de moins.
Je pense que la question est fausse.
Toutes les startups auxquelles j'ai participé n'avaient pas d'architecture FE-BE uniquement.
La plupart des startups que je connais ont:
- Core - le produit réel qui expose une interface
- UI - BE et FE. Le BE utilise l'API du Core.
Les API sont sans état et se moquent facilement, même sans avoir besoin d'un développeur principal. Enfer, si je devais démarrer un projet à partir de zéro, je pourrais commencer avec une interface utilisateur entière qui fonctionne uniquement sur des simulations - ce qui sera parfait pour les présentations. La plupart des commentaires sont dus à l'interface utilisateur. Les clients notent que plus dépend de votre public cible.)
Par exemple - Google Search a le composant Core qui explore le Web, l'indexe etc. et l'interface utilisateur de Google est un monde totalement différent. Ce noyau peut facilement prendre en charge les recherches non WWW, contrairement à l'interface utilisateur.
De cette façon, votre interface utilisateur est "enfichable" et vous avez une séparation des préoccupations.
Vous avez fait référence aux connaissances en développement, mais vous négligez les aspects de gestion de projet. Alors que l'équipe principale peut avoir besoin d'une durée de sprint de 2 semaines, l'équipe de l'interface utilisateur utilisera CI - tout est téléchargé tout le temps. L'équipe principale aura besoin d'une compatibilité descendante, contrairement à l'interface utilisateur.
La langue diffère. Vous voudrez probablement des développeurs C pour le composant Core - et vous serez d'accord s'il fonctionne sur un seul système d'exploitation, alors que l'interface utilisateur sera écrite dans un langage Cross OS.
Les tests diffèrent. Le monde des tests d'interface utilisateur est l'un des plus complexes que je connaisse dans le développement de logiciels. La plupart des startups le négligent et regrettent cette décision plus tard. Vous ne pouvez pas séparer BE et FE lors des tests. Il doit s'agir d'une seule unité qui le gère.
Interface utilisateur Open Source - l'un des plus grands avantages de la séparation des deux est que vous pouvez ouvrir la source de votre interface utilisateur. Le projet d'interface utilisateur a besoin d'un support open source.
Je ne peux pas imaginer un développeur d'interface utilisateur qui ne puisse pas comprendre la fonction --- (entiersession. Vous savez - où vous vous connectez et restez connecté entre différentes demandes. Certes, ils pourraient savoir PHP et non Java .. mais le concept BE doit être clair (par exemple, utiliser un cookie crypté). La barrière linguistique spécifique est erronée - chaque développeur doit être prêt à travailler dans n'importe quel Qui aurait cru qu'ils écriraient BE en JavaScript il y a quelques années?
Si vous continuez à avoir 3 équipes: Core, BE et FE, c'est un gaspillage de ressources à mon humble avis. Et DB? devez-vous avoir des DBA? Pourquoi un développeur BE devrait-il connaître DB et un développeur FE ne devrait-il pas connaître BE et DB? Il n'y a aucune limite.
Si vous avez besoin d'experts, et vous le ferez, l'externalisation fonctionne plutôt bien. Ils fournissent généralement du code de qualité et le font assez rapidement. Vous ne les voulez pas nécessairement en interne car vous vous perdrez s'ils partent. De plus, vous pouvez obtenir d'excellents conseils en ligne dès aujourd'hui. Les trucs de pointe peuvent nécessiter une approche différente.
Ainsi, le résultat est fondamentalement un BE très mince dans l'interface utilisateur que chaque développeur FE peut développer. Si vous avez un BE épais dans l'interface utilisateur, vous avez très probablement des fonctionnalités d'API requises dans le Core.
Il y a toujours au moins un développeur qui se démarque des autres. Compte tenu d'une FE aussi mince, il/elle peut gérer le support (pas le développement) d'autres développeurs en code BE. Mon avis est que ce développeur est en très bonne position et devrait être récompensé de manière appropriée (pas en salaire cependant, autre chose). J'espère également qu'ils seront en mesure de gérer le processus de construction et de construire correctement.
Ce modèle vous donne une grande flexibilité concernant le développement BE. Le monde BE a connu plusieurs revirements au cours des deux dernières années, je ne recommande donc pas trop de compter sur la stabilité BE. Core est une autre histoire.
Reste la question - FE et BE doivent-ils être les mêmes projet? Vous devriez noter ce qui suit
- Les ressources statiques sont mieux servies à partir du serveur frontal. Étant donné que les serveurs frontaux (par exemple nginx) sont très puissants et que vous pouvez utiliser le cache pour les ressources statiques, vous pouvez gérer avec un seul déploiement de vos ressources statiques (qui devraient être tout le contenu HTML, JS, CSS, Images).
- Le code backend n'a pas les mêmes luxes, vous devez donc avoir un système distribué - qui est également géré par un serveur frontal.
- Le code FE doit être réutilisé avec toutes les nouvelles technologies qui prennent en charge JavaScript. Vous pouvez désormais écrire des applications de bureau et mobiles avec JavaScript.
- Le processus de construction est complètement différent - et cela peut même inclure la livraison de correctifs, la mise à niveau, l'installation, etc.
Je peux continuer, mais j'espère qu'il est clair que je pense que BE et FE devraient être la même équipe, mais peut-être des projets différents.
Je pense que la mise en œuvre réussie pourrait être un certain nombre de choses. S'il y a un développeur unique qui a un backend solide mais qui a également une bonne compréhension de l'interface utilisateur et de toutes les pièces "front-end", alors il pourrait probablement réussir. Ce n'est généralement pas le cas (dans mon expérience personnelle). Par exemple, je me considère comme un développeur back-end. Mais je travaille sur beaucoup de projets par moi-même. Est-ce que je travaille sur la présentation et les pièces côté client? Sûr. Est-ce qu'ils ont l'air aussi bons que le feraient un concepteur et un développeur côté client? Absolument pas.
Tout va et vient. Mais ne laissez pas la collaboration de deux développeurs vous faire hésiter. Il existe des méthodes éprouvées pour maximiser la production entre un développeur et un concepteur.
En d'autres termes ...Cela dépend