云开发模式下的研发职能洗牌和工程模型
本文是对11月7日腾讯Techo技术大会上本人分享的议题《云开发模式下的工程模型和落地实践》的讲稿整理。
软件开发经历几十年的发展到今天，开发者的关注点其实只有两个：系统架构和软件架构。下图中列出的内容有的属于系统架构层面，比如异地容灾、网络专线、网络防护等等；有些属于软件架构层面，比如数据库、高并发、文件存储等等。
不论是系统架构还是软件架构，目的都是保证业务逻辑的正确性和高效性。换句话说，都是围绕业务逻辑展开。
以这两个关注点为基础，逐渐演化出了现今普遍的技术研发团队的职能分配结构。比如以系统架构为基础演化出运维工程师，又可细分为面向软件的运维和面向硬件的运维；以软件架构为基础演化出数据库工程师、服务端工程师以及前端工程师。
各职能有不同的分工，要求从业者具备其所属职能的专有领域知识，进而造成各职能之间存在明显的隔离边界。而边界的存在必然会对多职能的协作和交流产生不良影响。
极限编程是Kent Beck在1996年提出的一种软件工程方法，后又演化出三种耳熟能详的具体落地方案：封闭开发、敏捷开发和结对编程。前两者跟本文的话题关联不大，所以略过。下图展示的便是经典的前后端结对开发的场景：
虽然结对编程缩短了空间距离令沟通更便捷，但是空间并非是影响沟通的唯一甚至主要因素。由于前后端之间存在明显的职能边界，所以现实中的结对编程绝大多数达不到理想中的结果。而空间距离的缩短不仅没有促成高效沟通，反而弄巧成拙为两人的吵架提供了便利。
而这个问题在云开发模式下被极大地弱化甚至完全消除。为何会如此，我们先从云计算的历史讲起。
从系统到软件，云计算的演进之路
从物理机到云主机再到PaaS，云计算一步步降低了开发者对于系统架构的关注，减少运维投入和经济成本。Serverless则更进一步，弱化开发者对软件架构的感知和关注。
那么FaaS+BaaS的Serverless模型还缺什么？云开发如何弥补Serverless的不足？
举个例子，下图是使用云开发提供的云存储能力进行静态文件的上传和下载操作：
与传统CDN不同的是，云存储上传文件后得到的是一个fileID而不是URL，然后在下载的时候首先要用fileID换取URL，在这个过程中会进行必要的权限验证，非法用户不能够获得资源的URL。
从以上对比中可以提取出云存储相对于传统CDN的两个提升点：一是更安全便捷的权限控制；二是更语义化的编程语言API。
这也是云开发在Serverless基础上解决对端“最后一公里”问题的两个核心出发点。
关于云开发对于Serverless的加强请参阅延伸阅读《云开发如何解决serverless对端的最后一公里问题》。
云开发推动研发职能结构的洗牌
自BFF诞生以来一直存在着“BFF层谁来做”的争议。BFF层本质上是server，要求开发者有服务端开发的领域知识和能力。所以交给传统的前端工程师来做必然会有一定的学习成本以及服务稳定性方面的隐患，即使直接招聘有此能力的前端也会消耗相对传统前端更多的雇佣成本。
那么BFF交给后端开发者不就行了吗？如此，那跟传统的研发职能分配有何不同呢？前端仍然写交互、后端仍然写逻辑，协作流程上没有任何改动，意义何在？效率何在？
如此难以抉择的根本是因为前端工程师不会写业务逻辑？还是因为前端不熟悉服务端的编程语言？
当然不是。
编程语言是各职能之间最表层也是最容易跨过得一道门槛，业务逻辑则更不是问题。传统前端之所以写不好server，本质上是因为缺乏服务端开发的专有领域知识，而这些领域知识是跟编程语言和业务逻辑无关。
所以，云开发模式下由云函数承载业务逻辑充当BFF层的代替者，对于开发者的唯二要求便是熟悉编程语言和编写业务逻辑的能力，而与两者无关的其他领域知识一概消除。
则必然，前后端分离的边界下沉到BFF之下，进而传统的前后端职能分配结构被重新洗牌。
而洗牌之后的工程模型也更新换代。
研发职能的单一化必然带动迭代效率的提升，从另一方面，前后端由单一职能负责也提供了玩更多花样的环境，比如同构编程。
总结
虽然目前普遍认为Serverless=FaaS+BaaS，但Serverless是一种理念，一种指导思想，并不会局限于固定的模型。云开发在Serverless理念的基础之上，以端SDK+接入层的模式弥补了Serverless对端能力的不足。在此基础之上，传统的研发职能结构被进一步洗牌。
延伸阅读：
腾讯云开发者
