云开发模式下的研发职能洗牌和工程模型

软件开发经历几十年的发展到今天，开发者的关注点其实只有两个：系统架构和软件架构。下图中列出的内容有的属于系统架构层面，比如异地容灾、络专线、络防护等等；有些属于软件架构层面，比如数据库、高并发、文件存储等等。

虽然结对编程缩短了空间距离令沟通更便捷，但是空间并非是影响沟通的唯一甚至主要因素。由于前后端之间存在明显的职能边界，所以现实中的结对编程绝大多数达不到理想中的结果。而空间距离的缩短不仅没有促成高效沟通，反而弄巧成拙为两人的吵架提供了便利。

而这个问题在云开发模式下被极大地弱化甚至完全消除。为何会如此，我们先从云计算的历史讲起。

从物理机到云主机再到PaaS，云计算一步步降低了开发者对于系统架构的关注，减少运维投入和经济成本。Serverless则更进一步，弱化开发者对软件架构的感知和关注。

那么FaaS+BaaS的Serverless模型还缺什么开发如何弥补Serverless的不足/p>

举个例子，下图是使用云开发提供的云存储能力进行静态文件的上传和下载操作：

关于云开发对于Serverless的加强请参阅延伸阅读《云开发如何解决serverless对端的最后一公里问题》。

自BFF诞生以来一直存在着“BFF层谁来做”的争议。BFF层本质上是server，要求开发者有服务端开发的领域知识和能力。所以交给传统的前端工程师来做必然会有一定的学习成本以及服务稳定性方面的隐患，即使直接招聘有此能力的前端也会消耗相对传统前端更多的雇佣成本。

那么BFF交给后端开发者不就行了吗此，那跟传统的研发职能分配有何不同呢端仍然写交互、后端仍然写逻辑，协作流程上没有任何改动，意义何在率何在/p>

如此难以抉择的根本是因为前端工程师不会写业务逻辑是因为前端不熟悉服务端的编程语言/p>

当然不是。

编程语言是各职能之间最表层也是最容易跨过得一道门槛，业务逻辑则更不是问题。传统前端之所以写不好server，本质上是因为缺乏服务端开发的专有领域知识，而这些领域知识是跟编程语言和业务逻辑无关。

所以，云开发模式下由云函数承载业务逻辑充当BFF层的代替者，对于开发者的唯二要求便是熟悉编程语言和编写业务逻辑的能力，而与两者无关的其他领域知识一概消除。

研发职能的单一化必然带动迭代效率的提升，从另一方面，前后端由单一职能负责也提供了玩更多花样的环境，比如同构编程。

虽然目前普遍认为Serverless=FaaS+BaaS，但Serverless是一种理念，一种指导思想，并不会局限于固定的模型。云开发在Serverless理念的基础之上，以端SDK+接入层的模式弥补了Serverless对端能力的不足。在此基础之上，传统的研发职能结构被进一步洗牌。