本文来自蚂蚁集团数字金融余额宝体验技术组的奇谈，在支付宝体验科技沙龙上的分享：《基于Serverless的大前端轻研发平台-业务前端研发模式探索》。
随着智能化、Serverless等技术的发展，未来业务前端的发展趋势会是怎样呢？在蚂蚁大流量金融业务背景下，前端如何实现安全生产呢？本次分享会先介绍蚂蚁集团的前端研发体系现状，以及在大流量金融业务安全生产的背景下，前端研发工程师所要面临的研发效能和风险防控挑战等等一系列问题。最后会介绍我们基于Serverless的轻研发模式在尝试和探索解决这些问题中的实践。
希望大家能够从蚂蚁轻研发平台演进的设计思考中，获得一些启迪与新思路。
蚂蚁集团业务前端研发体系先来看一下蚂蚁集团的业务前端研发体系，按照业务类型分，可以分为PCweb，H5，小程序，native和大屏，我们余额宝以H5，BFF和小程序居多。
在业务上首选前端低码平台，其次是前端应用开发框架。图下面可以看到有一块是服务端部署，在蚂蚁或者阿里内部，BFF是前端的一个特点。那么什么是BFF呢？
BFF是BackendForFronted，它可以做请求聚合、数据裁剪等工作，因为前端是我们开发的，我们可以组织数据让它更适合于前端的交互。
上面大致介绍了蚂蚁业务前端的研发体系，下面我们看一看在实际的前端开发流程中，前端需要做哪些事情，以及哪些可以提效的点。
上面的流程大家应该都比较好理解，这里重点提一下“系分”"测分"，系分是系统分析设计，测分是关于测试的分析设计。那系分主要做什么呢？做需求的调研，功能的设计实现，以及需要注意的点，比如扩展性、可维护性、关键代码如何实现等等，总的来说就是你站在系统的角度要如何设计这个功能，同时又能最好的实现需求。
系分一般产出的有流程图，时序图，接口设计说明等等文档。既然有文档，那就有一个地方保存它们。大家在需求前期阶段应该遇到过需求变更的情况，需求变更带来的问题是我们的系分可能要更改，频繁的变更带来的问题是我们的系分文档不保鲜，不保鲜的意思是系分文档已经和最终的需求不一致了，可能是小的需求变更我们懒得去更改，脑子记住就好了，也可能是文档比较多，散落在各个地方，懒得去一个一个找了。
再来看编码过程，企业级的应用打包部署慢，企业级应用通常意味着代码复杂度较高，这是业务的复杂度带来的，另一方面是复杂度带来的依赖多。
最后看一下上线阶段。我们的用户基数大，对安全生产的要求高，带来的问题就是兜底代码多。这个兜底代码是什么呢？比如，如果某一天有个接口或者依赖挂了，我要有监控能主动感知到前端报错了，我们的页面不能直接崩溃，我们会有缓存、重试、降级等等方案来最大限度保证体验。在小公司我一个需求可能3天就搞完上线了，但是在蚂蚁，同样一个需求，我要花5天甚至6天，这多出来的时间就是在搞降级、监控等。
总结起来就是，BFF的引入+安全生产要求高（金融类业务）带来前端研发复杂度增加。
那我们如何解决这个问题呢？针对上面的3类可以提效的点，我们分别用“文档即代码”，“函数级研发部署”，“一体化研发环境插件能力”核心思想来提效。
先看第一个核心思想：“函数级研发部署”我们将多应用级（前端+BFF）利用Faas技术变为函数级的研发部署。关于Faas的具体技术细节，可以参考齐穹的《手把手搞定渐进式NodeFaas》，在我们的支付宝体验科技视频号可找到。
针对BFF接口，函数级研发部署具有开箱即用，无环境依赖，独立部署等特点。你不需要在本地安装一大堆依赖，搞各种环境问题。也不用为了抢占环境部署代码，每个接口都可以独立部署。
函数级研发不只是能开发BFF接口，它还能开发前端一体化卡片。可以看下面这张图：
卡片是在页面上相对独立的一块区域。比如我上面这张，它的UI和数据高度内聚，是一个整体，我们可以把UI和数据一起下发。说到这里，我要重点介绍一下前端开发的历史转变。
刚开始我们叫传统模式，典型的是PHP、JSP等，我们把静态页面开发好，交给后端，后端用脚本语言替换动态数据，最终把整个页面一起返回给浏览器。
这种模式前后端非常耦合，不利用维护和并行开发，我们有了前后端分离模式。典型的是Ajax技术的兴起，前端专注开发页面，后端专注开发服务，前后端的交互通过Ajax请求传输数据，这样前后端就可以并行开发了。
前后端开发让我们专注各自的领域，但经常我们前端为了让数据更适合于前端交互，会做一些请求聚合、数据裁剪等工作，后来有了BFF，更早的时候我们还是叫直出，BFF让我们可以使用统一的技术栈编写数据服务等一部分后端工作。但它仍然还是分成了前端和BFF，既然技术栈都统一了，为什么还要分前后端呢？
所以我们又回到了传统模式，前端UI+数据一起下发，它可以解决前后端依赖问题。比如你不用担心忘记发布BFF接口导致的前端报错了，也不用担心历史的接口如何向前兼容的问题了，因为我们的数据和UI是一起下发的，没有接口这一层了。
上面的图演示了一体化卡片开发。
下面来看核心思想2：文档即代码我们将需求、视觉、系分、测分、代码等等集中管理起来，在一个上下文中，以此来解决文档代码不保鲜。我们还可以利用智能化等技术，自动从文档中生成关键代码、流程图、时序图等，让我们的文档和代码保持同步。
上面这张图演示了文档即代码，可以看到，在我们的研发体系化环境中，需求、视觉、网关配置、接口设计等等各种相关的文档集中在一起，你不需要在各个独立的文档中来回切换。一个小的需求变更，我们顺手就改掉了各个相关的地方。
文档即代码不是简单的把各种类型的文档聚合起来就好了，我们可以通过自动化、智能化等技术，将非结构化、结构化的文档生成我们想要的代码，提高我们的研发效率和质量。
比如我们可以使用D2C能力，自动将视觉稿生成代码，通过文档中的配置信息，自动生成监控，应急预案等等。
下面这个视频演示了D2C在一体化研发平台上，如何从一个视觉稿到代码，到调试的流程。
那这些能力只能我们轻研发平台自己去做吗？显然不是，我们轻研发平台提供各个阶段的插件能力，你可以通过插件去定制适合你的工作流，也可以通过插件将现有的优秀的第三方能力复用进来。比如上面提到的D2C能力，就是基于保险团队的。
最后总结一下上面提到的。
轻研发平台三大核心思想文档即代码：将结构化、非结构化的文档集中管理起来，并通过智能化、自动化等技术生成代码函数级研发部署：BFF接口和一体化卡片，独立部署、开箱即用、无环境依赖一体化环境插件能力：复用优秀三方能力，定制你的工作流最后的最后，未来我们业务前端做什么？