在网络启动时，让工程师处理功能的前端和后端（主要负责整个功能）是否更常见？还是让工程师在后端和前端分开？
哪些更有益，哪些情况适合？
我已经注意到，由一位工程师来负责整个功能的缺点是，该人可能只在前端或后端开发方面特别强大，但不能同时兼顾两者，因此有时速度和质量都会下降。
前端和后端开发人员使用一项功能可以提高功能的速度和质量，并鼓励协作。但是我担心要有2位工程师在一个功能上工作，这可能会浪费资源，因为1位工程师可以放在另一个功能上进行工作。
在小型早期启动阶段分配后端/前端工程资源的常用/最佳实践是什么？然后随着它的增长它将如何变化？
Answers:
这是我从14年的经验中得出的智慧：
最好的答案来自@Shark，但只有最后一部分“取决于情况”。以大约16年左右的经验，我已经看到两种选择都在各种不同的配置中尝试过。我自己是一名全栈开发人员，这是我要学习的内容：
*（BE =后端，FE =前端）
敏捷开发实践（近来是当今的通用策略）推荐功能开发，从客户的角度来看，功能是功能的唯一有价值的卡盘。从这个角度来看，您应该让开发人员同时实现这两者。
沿着服务器边界拆分堆栈会在两个开发人员之间创建一个集成点。除非他们有效地沟通并良好地合作，否则这两个功能结合在一起时将导致大量错误。
应用《神话人月》中的n（n-1）/ 2个交流规则，您会发现在两个人之间将功能分为两个部分会增加您的整体工作量。当然，该规则也适用于功能，但是拆分堆栈会使通信量增加一倍。
设计人员将解决BE开发人员无法从头开始产生有吸引力的界面的问题。假设他们至少了解html和css，并且可以产生与设计人员创建的屏幕截图匹配的界面。
特征通常是与其他特征很少交互的隔离组件。并非总是如此，但通常交互点位于数据库或文件系统等较低级别。因此，没有什么可以阻止全栈开发人员实现其功能的。但是，如果FE开发人员必须等待BE开发人员完成任务，那么除了第3点的生产率损失之外，这还会增加更多的延迟。
Web2.0进一步模糊了FE和BE之间的区别。借助MVC框架，以及在客户端上构建整个应用程序，现在需要大量的BE知识来实现安全高效的FE应用程序。
我对此实践最大的抱怨是，它限制了参与该项目的每个人的能力。尽管在2000年代初期这是一种普遍的做法，但是这样做是不必要的，因为要找到能够同时做到这两者的开发人员是非常困难的（纯粹是因为新颖，而不是因为在学习两者上都存在一些固有的困难。）十年后，我们仍然有不了解CSS的“网络开发人员”。
我的第二大抱怨是，它可以轻松地划分一个开发团队。一名有限元开发人员在修改BE代码后创建了一个错误，团队投票限制了跨栈开发的批发。代码审查和教育可以解决问题，而人们却变成了领土。
RESTful API非常适合此描述，因为没有FE。通常，公司会首先使用RESTful API，然后再开发其Web应用程序。在这种情况下，有充分的理由让BE团队在FE完成申请的同时专注于下一个主要版本。但是流失的危险仍然存在-特别是如果在FE开发阶段发现的新信息要求对BE API进行不重要的修改。
FE和BE之间的工作负载不平衡也是创建仅FE团队的一个很好的例子。同样，这是非常情况，也许主要的开发是通过桌面应用程序完成的，而公司正在尝试开发“精简”的Web界面。
培训新/初级开发人员。如果您正在招聘一名实习生或初级开发人员，并且担心将其投入到深层开发中，那么将部分通信/集成成本投资到对等开发系统中是一个不错的选择。
第一点非常大胆-如果您没有其中一个“好的自组织团队”，它将很快失败。即使您拥有该团队，也要突破自己的界限，这符合您和他们的利益。优秀的自组织团队并不总是会自我激励。
您的第二点是错误的。现代Web开发需要功能强大，安全，异步安全，防XSS，跨浏览器且快速开发的FE代码。这些目标根本无法与BE竞争，它们实际上是平等的。
第三点也是一个错误的假设-FE开发可以从纯html / css / js开始，而无需任何BE基础工作。从那里开始，只需花费很少的精力就可以将其分解为BE渲染的模板。通常，最好是开始进行有限元工作，因为这会使利益相关者感到温暖而模糊，从而可以提前看到视觉效果。
结论：
如果您是一家初创公司，而您并没有花费大量时间或金钱，那么就不要雇用FE或BE只是开发人员。雇用高级Web开发人员和优秀的UX /设计人员，他们将尽快启动您的应用程序。它们的成本更高，但是它们的生产率要高得多，您将需要更少的它们。
我认为这个问题是错误的。
我参加的所有初创公司都没有仅限FE-BE的架构。
我知道的大多数创业公司都有：
API是无状态的，易于模拟-即使不需要Core Developer。地狱，如果我必须从头开始一个项目，我可能会从一个完全可以在模拟上工作的整个UI入手-这对于演示非常有用。大多数反馈归功于UI。客户注意到更多-（取决于您的目标受众。）
例如-Google搜索的核心组件可对网络进行爬网，对其进行索引等。而Google UI则是一个完全不同的世界。此核心可以轻松支持非WWW搜索，而UI则不能。
这样，您的用户界面是“可插入的”，并且您可以将关注点分离。
您提到了开发知识，但是忽略了项目管理方面。虽然核心团队可能需要2周的冲刺时间，但UI团队将使用CI-所有内容始终都上传。核心团队将需要向后兼容，而UI则不需要。
语言有所不同。您可能需要C开发人员来使用Core组件-如果它在单个OS上运行就可以了，因为UI将使用跨OS语言编写。
测试有所不同。UI测试世界是我在软件开发中所知道的最复杂的世界之一。大多数初创公司都忽略了它，后来对此决定感到遗憾。测试时不能将BE和FE分开。它必须是处理它的单个单元。
开源用户界面-将两者分开的最大好处之一就是您可以开源用户界面。UI项目需要开源支持。
我无法想象一个不能理解整个 session功能的UI开发人员。您知道-在不同的请求之间登录并保持登录状态。的确，他们可能知道PHP，而不是Java。.但是BE概念应该清楚（例如，使用加密的cookie）。特定的语言障碍是错误的-每个开发人员都应该愿意使用任何语言。谁会想到几年前他们会用JavaScript编写BE？
如果您继续拥有3个团队：Core，BE和FE，恕我直言，这是对资源的浪费。那DB呢？你应该有DBA吗？为什么BE开发人员知道DB而FE开发人员却不知道BE和DB？没有限制
如果您确实需要专家，则将他们外包很有效。他们通常会提供高质量的代码，而且速度很快。您不一定希望他们在公司内部，因为如果他们离开，您将会迷路。此外，您今天可以在线获得很好的建议。尖端的东西可能需要不同的方法。
因此，结果基本上是每个FE开发人员都可以开发的UI中非常薄的BE。如果用户界面中的BE较厚，则很可能在Core中需要一些API功能。
总是有至少一位开发者在其他领域脱颖而出。给定如此薄的FE，他/她可以在BE代码中设法提供支持（而不开发）其他开发人员。我的观点是，该开发人员的处境非常好，应该得到适当的奖励（尽管没有其他薪水）。我也相信他们将能够处理构建过程并正确构建。
此模型为您提供了有关BE开发的极大灵活性。在过去的几年中，BE世界已经知道了几个转变，因此我不建议过分依赖BE稳定性。核心是另外一个故事。
仍然存在一个问题-FE和BE应该是同一个项目吗？您应该注意以下几点
我可以继续，但是我希望很明显，我认为BE和FE应该是同一个团队，但可能是不同的项目。
我认为成功实施可能是几件事。如果有一个单一的开发人员，它具有强大的后端功能，但在用户界面和所有“前端”方面也有不错的把握，那么它可能会成功。不过，以我个人的经验来看，情况通常并非如此。例如，我认为自己是后端开发人员。但是我自己一个人从事很多项目。我要处理演示文稿和客户端部分吗？当然。他们看起来和实际的才华横溢的设计师和客户端开发人员一样好吗？绝对不。
这都是给与取。但是不要让两个开发人员的合作让您犹豫。在开发人员和设计师之间，存在尝试和真实的方法来最大化生产。
换句话说... 这取决于
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.