在web开发项目中，将后端和前端划分为两个位置是常见的吗？

Question

在一家网络初创公司，让工程师负责功能的前端和后端(基本上负责整个功能)是否更常见？还是工程师们把后端和前端分开了？

哪些方案更有益，哪些情况下更有利？

我注意到，关于由一名工程师负责整个功能的缺点是，这个人可能只在前端或后端开发中特别强大，而不是两者都很强，因此有时速度和质量都会下降。

让前端和后端开发人员在一个特性上提高功能的速度和质量，并鼓励协作。但我担心的是，有2名工程师在一个功能上工作，这可能是一个资源使用不良的问题，因为1名工程师可以被安排在另一项功能上进行工作。

在小型早期启动阶段，分配后端/前端工程资源的通用/最佳实践是什么？那么，随着它的成长，它将如何变化呢？

Answer 1

以下是我14年经验的智慧：

• 如果你有一个创业公司，不要分配角色。希望你能组建一个很好的自我组织的团队。如果每个人都认识对方，每个人都知道谁做得最好。项目经理只会挡道。
• 后来，区分前端和后端是有意义的。在后端，质量是prio之一。代码必须具有表现性、安全性和事务安全性。在前端，实现时间很重要。而且你必须能够依靠一个好的后端。前端和后端的不同目标不能很好地结合在一起。
• 在前端编码器开始工作之前，后端应该已经存在了。否则，前端编码器将放慢太多。
• 后端必须能够快速响应前端的需求，以避免减慢它们的速度。

Answer 2

最好的答案是“鲨鱼”，但只有最后一部分“它取决于”。根据我的经验，大约16年左右，我看到这两种选择都尝试在各种不同的配置。作为一个完整的堆栈开发人员，下面是我要学习的内容：

*(BE =后端，FE =前端)

拆分堆栈开发的一般注意事项：

1. 敏捷开发实践(现在是一种常见的策略)推荐特性开发，从客户的角度来看，特性是一种有价值的功能选择。从这个角度来看，您应该让您的开发人员实现这两者。
2. 沿着服务器边界分割堆栈将在两个开发人员之间创建一个集成点。除非它们进行有效的沟通和良好的协同工作，否则当这两个特性结合在一起时，就会产生相当数量的bug。
3. 应用神话人物月的n(n-1)/2通信规则，您将看到两个人之间将功能分成两部分，这将增加您的总体工作量。当然，该规则也适用于特性，但拆分堆栈会使通信量翻倍。
4. 设计师将解决开发人员无法从零开始产生有吸引力的界面的问题。这假设他们至少知道html & css，并且可以生成一个与设计人员创建的屏幕截图相匹配的界面。
5. 特性通常是孤立的组件，与其他功能的交互很少。这种情况并不总是如此，但通常情况下，交互点处于较低的级别，如数据库或文件系统。因此，完全堆栈开发人员无法实现他们的特性。但是，如果FE开发人员不得不等待BE开发人员完成一项任务，那么在第3点的生产力损失之外，它还会增加更多的延迟。
6. Web2.0进一步模糊了FE和BE之间的区别。随着MVC框架和整个应用程序构建在客户端，现在需要大量的BE知识来实现安全高效的FE应用程序。
7. 我对这种做法最大的不满是它限制了每个参与这个项目的人的能力。虽然这是2000年初S的一种普遍做法，但这是出于必要，因为找到既能做到又能做到的开发人员相当困难(纯粹是因为新的原因，而不是因为两者都有一些内在的困难)。剩下的做法是，十年后，我们仍然有不懂CSS的"web开发人员“。
8. 我的第二大抱怨是，它可以很容易地分割一个开发团队。FE开发人员在修改BE代码后创建一个bug，团队投票决定限制跨堆栈开发。虽然代码评审和教育可以解决这个问题，但人们却变成了属地。

好处/用例-拆分堆栈开发用例：

1. RESTful API非常适合这种描述，因为没有FE。通常，一家公司会首先开发一个RESTful API，然后在上面开发他们的web应用程序。在这种情况下，在FE完成应用程序时，有一个很好的理由让BE团队专注于下一个主要版本。但是搅动的危险仍然存在--特别是如果在FE开发阶段发现的新信息需要对BE API进行非平凡的修改的话。
2. FE与BE之间的工作负载不平衡也是创建FE专用团队的一个很好的例子。同样，这也是非常符合实际情况的，也许主要的开发是通过桌面应用程序完成的，公司正在尝试开发一个“lite”web界面。
3. 培训新开发人员/初级开发人员。如果您正在雇用实习生或初级开发人员，并担心将其投入深度，那么将部分通信/集成成本投资于同侪开发系统是一个不错的选择。

对@Ralf在本页上接受的答案的关注：

1. 第一点是相当大胆的--如果你没有这样一个“良好的自我组织团队”，它很快就会失败。即使你有那支球队，突破他们的界限也符合你和他们的利益。而良好的自我组织团队并不总是自我激励的。
2. 你的第二点就是错了。现代web开发需要性能好、安全可靠、异步安全、抗XSS、跨浏览器和快速开发的FE代码.这些目标根本不与之竞争，因为它们实际上是平等的。
3. 第三点也是糟糕的假设-- FE开发可以从纯html/css/js开始，而无需任何基础工作。从那里开始，将其分解为正在呈现的模板只是一项琐碎的工作。通常情况下，最好从FE工作开始，因为它会给利益相关者一种温暖而模糊的感觉，让他们看到眼前的视觉进展。

结论：

如果你是一家初创公司，而且你没有太多的时间或金钱去消耗，那就不要雇佣FE或者仅仅是开发人员。聘请高级网页开发人员和一个优秀的用户/设计师，他们将尽快得到你的应用程序。它们的价格更高，但它们的效率要高得多，而且你所需要的也会更少。

Answer 3

我认为这个问题是错误的。

我参加过的所有初创公司都不是只有FE架构的。

我认识的大多数初创公司都有：

• 核心-公开接口的实际产品。
• UI - BE和FE。BE使用Core的API。

API是无状态的，很容易被模仿--即使不需要。见鬼，如果我必须从头开始一个项目，我可能会从一个完全在模拟上工作的整个UI开始--这将是非常适合演示的。大部分反馈都是由UI引起的。顾客注意到更多-(取决于你的目标受众)。)

例如，Google搜索有一个核心组件，它可以抓取网页，索引它等等。谷歌用户界面是一个完全不同的世界。这个核心可以很容易地支持非WWW搜索，而UI不能。

这样，您的UI是“可插拔的”，并且您有不同的关注点。

您提到了开发知识，但是您忽略了项目管理方面。虽然核心团队可能需要2周的冲刺持续时间，UI团队将使用CI -所有的东西都上传所有时间。核心团队需要向后兼容性，而UI则不需要。

语言不同。您可能需要C开发人员为核心组件-如果它运行在一个单一的操作系统上，因为UI将编写为跨OS语言。

测试各不相同。UI测试世界是我所知道的软件开发中最复杂的领域之一。大多数初创企业都忽视了这一点，并对后来的决定感到遗憾。测试时不能分离BE和FE。它必须是一个处理它的单一单位。

开源UI --将两者分开的最大好处之一是你可以开源你的UI。UI项目需要开源支持。

我无法想象一个UI开发人员无法理解整个session特性。您知道-在不同的请求之间登录并保持登录的位置。没错，他们可能知道PHP，而不是Java。但是BE的概念应该是明确的(例如使用加密的cookie)。具体的语言障碍是错误的-每个开发人员都应该愿意在任何语言中工作。几年前，谁会想到他们会用JavaScript写字呢？

如果你继续拥有3个团队:核心团队、BE团队和FE团队，这是对资源的浪费。那DB呢？你应该有DBA吗？为什么BE开发人员应该知道DB而FE开发人员不知道BE和DB？是没有限制的。

如果你需要专家，而且你会的话，外包他们会很好。他们通常交付高质量的代码，而且他们做得相当快。你不一定要他们在家里，因为如果他们离开，你就会迷路。此外，你今天可以在网上得到很好的建议。尖端的东西可能需要不同的方法。

因此，结果基本上是一个非常薄的UI，每个FE开发人员都可以开发。如果您在UI中有一个很厚的BE，那么您很可能在Core中需要一些API功能。

总是至少有一个开发人员在其他项目中脱颖而出。考虑到这么瘦的FE，他/她可以设法在BE代码中支持(而不是开发)其他开发人员。我的看法是，这个开发商处于一个非常好的地位，应该得到适当的奖励(而不是在薪水，其他东西)。我也相信他们能够正确地处理构建过程和构建。

这个模型为您提供了非常大的灵活性。在过去的几年里，BE世界经历了几次翻天覆地的变化，所以我不建议过于依赖稳定。核心是另一个故事。

还有一个问题-- FE和是同一个项目吗？您应该注意到以下几点

• 静态资源最好是从前端服务器提供。因为前端服务器(例如nginx)非常强大，而且您可以使用缓存来处理静态资源，所以您可以使用静态资源的单个部署来管理(这些资源应该是HTML内容、JS、CSS、图片)。
• 后端代码没有相同的奢侈品，所以您必须拥有一个分布式系统--它也由前端服务器管理。
• FE代码可以与所有支持JavaScript的新技术高度重用。现在您可以使用JavaScript编写桌面和移动应用程序。
• 构建过程完全不同--甚至可以包括补丁交付、升级、安装等。

我可以继续，但我希望这是明确的，我认为BE和FE应该是同一个团队，但可能是不同的项目。