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 toute la session
fonctionnalité. Vous savez - où vous vous connectez et restez connecté entre différentes demandes. Il est vrai qu'ils connaissent 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 disposé à travailler dans n'importe quelle langue. 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 pas de 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 pourraient 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 opinion 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 le même 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.
if you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best.