2020 国内公司前端团队都在搞些什么?

这个问题要强答一波，好多开发不知道自己要干什么，视野打不开，以下有的是在工作中看到同事在做的，有的是自己参与的，列举出来，大家可以看看，扩展下思路

建立开发规范，最重要的就是 git 分支使用规范，至少有个 release 分支对应生产环境，pre 对应预发，qa 对应测试环境
建立统一的项目模版，比如单页，多页，后台管理，组件开发，小程序，Nodejs 项目，然后通过 cli 来选择项目模版，模版选择后，直接生成项目，然后把调用 gitlab 的 api，在 gitlab 上创建项目，push项目，这样就收拢了大家创建项目的方式，自动统一了代码规范
基于上面这个，就可以做基于 gitlab ci/cd，阿里云 oss 的持续集成，完成 push =&> 构建 =&> 上传oss（或者静态资源伺服器,自动绑定域名，接 cdn，这样一条龙的服务，人手够的话也可以把 2，3结合一起做成基于 GUI 网页的创建，因为这里接管了大家发布代码的规范，后面就可以干很多事了
把内部的 npm 私服搭建起来，做一套内网的 npm 组件开发构建 publish 一条龙服务，建一个组件展示平台，这样人多了，大家接可以互相用起来，方便的很
因为有了上面 3 的收拢，我们就可以上线代码风格校验，检测线上发布是否包含了 sourcemap文件，接著人手够，老板支持的话，可以统计每个项目的依赖，存储到资料库，这样某天某个第三方出了问题（比方包含了挖矿脚本），就能立马找到那个项目依赖了，对于内部 npm 组件，谁使用了，也是很清晰，这样组件更新了，也可以企微，钉钉，邮件的方式自动通知到使用方，再大胆些，还可以每次发布前通过 puppeteer 跑下项目，统计了性能数据，和之前的数据对比下，偏差太大也可以通知到对应负责人，让他检查下
建立监控体系，监控体系可以简单，可以复杂，看领导的支持度，最基础的功能是，做 pageLoader 监控，意思是页面载入成功后上报下数据，表明当前页面是正常的，这样每次上线后，就通过消息通知到开发去观察 pageLoader 曲线的变化，这样就不会发布后， 2 眼一抹黑，也不知道线上是个什么情况，出了问题，也可以通过 gitlab ci/cd 立马回滚代码，这个是个很强的需求，基本上老板肯定是支持的，那线上出了错也不知道是啥子错，咋办，那我们把线上错误上报上来，就很直观了，还可以结合 sourcemap 把错误和打包前的文件映射起来，便于定位问题，没人手就用开源的有 sentry，有人手的就自己开发
监控建立起来了，是不是得做个报警机制啊，比方某个桥接更新了，和之前的不兼容，之前运行好好的的页面一直报错，错误上报达到一定量就报警起来，那就去把上报的数据捞起来做个统计分析，还可以结合 prometheus，做个好看展示曲线
既然错误监控都做了，那把页面性能监控也做了吧
哎，咋监控后性能数据这么差，是哪里出了问题，哦，打包文件太大，那 Webpack 得好好学习下，怎么拆分，啊，发现 http 请求时间太常，是不是 CDN 哪里出了问题，是不是资源没开启压缩，那这个链路还不熟，得好好学习下
什么前端的监控都给做了，能不能协助下客户端的同学，把他们的 crash 上报，冷启监控都给做下
要做上面这些，至少需要会门后端语言，会资料库啊，我擦，刚好上手 Egg.js Mysql 开发啊，之前不是学习 Node.js 没有场景使用么，一下子这么多场景来了，刚好带薪学习
我擦，接了前端，客户端上报，请求数量一下子上来了，随手写的垃圾 Egg 代码，性能跟不上了，加班优化吧，不然不被骂死，还不行，加机器吧，加机器要做负载均衡啊，这个不会啊，赶紧学习去，是不是还需要做缓存，那还得学习下 Redis
活动页天天写，可是有很多落地页都是非常简单的，每次都得 copy 个项目，然后改改图片，改改样式，太烦了，没有成长啊，那要不我来整个托拉拽生成页面，把这些页面元素都独立成组件，让运营自己去拖动，生成她需要的，这不就是个就是时髦的「可视化搭建么」把自己解放出来
简单的落地页可以这样整，那难的活动页咋办，比如大转盘，红包雨，发现这些活动复杂些，简单的搭建不好解决，但是发现，这些好像也可以抽象，抽象成玩法的概念，那得加个配置中心来配置玩法
发现每个项目组活动页有自己不同的 api，还有些活动会用相同的api，怎么办，每个人还不一样，我擦，这样配置中心用起来太麻烦了，是不是做个服务平台，把这些 API 都包成 BaaS，然后想用的人自己谢谢代码来组合 api ，那这个要用 Fass 了，额，一步小心，做了个粗糙版的 Serverless

上面的 1 ～ 6 条是超过 6个人前端组都可以干的事，大大节省人力，到现在我发现还有人，是把打包好的文件，拖动伺服器上去了，人肉打包机

7 ～ 12 15人左右的团队必须上了

13 ～ 15 每个单拎出来都是亮点项目，非常提升人效，也是晋升，跳槽很好吹水的点

上面这些听起来没有大家常听的那些时髦，比如 SSR，微前端这些，很多开发者总想著搞些时髦的技术，实际上解决公司当下的一些同事常常抱怨，经常重复的地方，更是我们应该做的，围绕当下业务，解决当下问题

如果觉得有帮助，点个赞伐

---------------------------------------- 分割线 ------------------------------------------

修改于：2020.10.23

额，另外，我最近加入蚂蚁花呗借呗前端 RichLab 团队，和楼下是个大BU下面的（^_^），如果你对我们团队感兴趣也可以加我微信聊聊，发展迅速，人员缺口非常大，不感兴趣也可以加呀，我们可以聊聊职场困惑，发展方向,

我微信base64：aGM5MzE2NDE1OTk= ，邮箱：[email protected]

我们在前端这个大方向设置了几个领域，总有一个适合你，如果你多这些都感兴趣

如果你想了解下怎么准备面试，我们需要什么样的人，看，我们老板完颜把这么准备面试都给写好了，真的是诚意满满的招人！！

ScottZao：前端搞面试 | 完颜 - 如何考察候选人的能力与潜力?

zhuanlan.zhihu.com

也可以看看我对入职我们团队的一些感受：

hucheng91：入职花呗借呗前端一个月感受?

zhuanlan.zhihu.com

我们团队介绍:

ulivz：蚂蚁金服 RichLab 团队邀你来聊一聊?

zhuanlan.zhihu.com

2020年马上就结束了，所以这个问题可以来回答一波了。

真2020年，我的前端团队都在搞些什么。

1，年初搞疫情。

在微博和新浪新闻客户端内的，疫情期间大家每天都看的，现在线上还在跑的，新浪全网在投的那个全国和世界疫情专题是我这边开发的，主要是图表可视化展示，二级页，涉及到了很多 echart 的二次开发，使用的技术比较 low，vue 配合 zepto……我们用 vue 开了一个动态模板在我们的后台里面再用 zepto 配合 echart 手写了很多图表组件，经历了多次性能优化，监控补点，包括 echarts 的 map 部分的很多省份，国家的数据修改等。经历过多次故障，兼容性的，性能的，数据的，最后又补了一套前端监控体系来保证这一坨（自己发挥想像）代码，因为那时候疫情远程在家，多个团队一起配合，而且一直以为是个临时活动需求而已，没想到一直坚持到了现在。

2，做了很多和 puppeteer 无头浏览器相关的工作。

我们开发了内部的一套无头浏览器集群，可以快速编排一些简单指令，封装成任务去做一些事情，什么事情都有，比如帮助编辑做文章二次排版美化，抓取排版，格式化等，网页截图，还有一些自动化的测试，爬虫等等都有涉及。核心还是在于把任务分发和任务算力与 worker 解耦后做的一套分散式的puppeteer 集群，可以智能控速，感知进度，发现异常，实时报警等等，真正的把技术转化成了公司生产力。

3，做了一个 electron 的在线会议客户端

系统的搭建了一套 electron 的集成构建环境，包括环境隔离，打包部署，代码签名，mac 和 windows 的代码验证，自动更新，异常抓取以及搞明白了怎么和 c++配合实现一些 electron 自身无法实现的功能，我们这边采用ffi-napi来调用c++编写跨系统的 DLL实现的部分会议功能，然后又撸了个 mqtt 的 IM。

4，正在准备升级一套新的 hybrid 架构升级

之前的离线包技术我们用了很多年，遇到一些瓶颈，目前正在做计划优化，比如之前每个 bundle 都是一个独立 zip 下发的，我们目前打算为了解决灵活更新的问题，加入了基础共享包的概念，想把一些模块化的方案带入到 native 本地去，这样共享包实现后，可以实现公共模块的更新让整个系统都能有收益，而且不需要频繁发版本，设计了版本控制，新的 ci/cd 依赖流程，app 新老版本兼容方案，以及本地开发调试的方法还有配合客户端做依赖检查，deps配置下发等。

之前我们的 app 内每个 hybrid 都是一套独立的 repo 仓库，今年也做了很长一段时间整合把 multi repo 改写成了 single repo，也是为了配合上面说的优化和灵活更新的问题而设计的，对此把相关的脚手架，上线流程又做了很大和之前不一样的调整。

5，Daruk 发布了2.0 作为一个跨年项目，从19年中开始，终于画了一个还不错的句号。

Daruk?

darukjs.com

6，新浪新闻终于开始尝试在主端试用 flutter 开发部分功能，我们这边也参与进来，最近在学 dart 语法和 flutter 的 api，主要负责和客户端一起配合调 channel，坑还很多，没有踩完。

7，调研过一阵新技术，比如 AR，webassembly，tensorflow啥的，最终结论暂时都还用不上……

8，搞了短时间的 faas，内部和运维一起搭建的，最终结论还是用不上……

9，搞了搞 DCG，做了几个小游戏来封热榜投票的，如果你玩微博给新浪爱豆投票的功能，应该遇到过。

10，部分业务前端接入了protobuf来开发。

11，做的事情挺多的，和业界时髦技术相关的一样没有，也不知道是不是掉队了。就这技术栈很怕35岁失业，焦虑中。

12，学了一些客户端的黑科技，比如用adb配合appuim写脚本去监控一些功能，最近打算升级到公司自己搭的stf上去，之前是找了个物理机弄了个简易机架，能干的事挺多的，不能细说。（狗头

喜欢的话可以转发让更多人看到。

这个问题的背后其实是好多前端同学对未来的迷茫。在前几年，前端突飞猛进，很多新技术接踵而至。虽然大家口口声声说学不动了学不动了，但大家至少有个目标可以去学。

五六年前，学个React或Vue，再引入到项目中。用ES6开发，配合gulp或grunt，搞个前后端分离的工程，那就很牛逼了，简直就是带著团队从石器时代迈入了工业时代。

然后过个一两年，再学个webpack，搭个更好的研发脚手架，再配合打包分析，做做性能优化。在团队内做个分享并推广下，又是很不错的技术产出了。

又过个一两年，再学学Node，有了服务端能力，配合gitlab、jenkins这些，前端可以自己搞个好用的发布系统、迭代系统，再引入前端监控服务等等，一套完成的前端基建就做的很完善了。又能继续成长、升职、加薪了。

问题来了，现在要做什么，现在能学什么？

去年阿里前端委员会主席圆心，《在未来前端的机会在哪里中》指出四大方向：

搭建服务
Serverless
智能化
IDE

但这对于大部分前端来说，这显得过于方向性，牵扯的东西太多了。它不像是一两个知识点，照著教程文档学一学，再看看源码什么的，就掌握的差不多了。而且很多似乎还超纲了，网上搜一下智能化、serverless，很多领域外的名词映入眼前，不知从哪学习。最最最为要命的是：我就算学会了，我的公司、我的业务，似乎也用不著这些知识点。

所以，很多同学开始焦虑、不知道该学什么，更不知道该做什么。基础技术基本成熟，业务上，前端似乎也就只能糊糊页面，很难再有发力点。

说了这么多，其实我也提不出什么非常好的方法论，但我觉得我们保险前端大团队整体做的还算不错，在这里介绍一下，看看能不能给其他同学多一些输出。

业务情况

首先还是简单介绍下我们这边的业务，空讲技术，没有任何背景。

商业险业务：其实基本涵盖各位认知的全部险种，寿险、健康金、财产险、意外险等等。还有你可能想不到的，比如退运费险、宠物险等等
相互宝业务：相互宝是我们这两年的明星产品，具体我也不多介绍了，总之是蚂蚁与集团重点事项。支付宝搜索相互宝可多了解
围绕保险产品的公估、理赔等各环节产生的B端服务：蚂蚁保险作为一个平台服务，会对接各类保司以及其他相关公司，同时也会给他们提供很多相应服务。

大致可以了解到，蚂蚁保险是一个同时面向BC端提供服务的平台级业务。下面正式说说我们前端现在在搞些什么。

技术事项

营销与运营体系

我先说我自己负责的部分吧。我目前负责保险用户增长相关的前端事项，所以围绕的是营销与运营体系。

智能组件

组件化想必都是所有的团队都会做的事情。除了类似antd、element这些基础UI组件之外，一般也会沉淀一些基础的业务组件，便于不同产品做类似功能复用。

一个C端页面，往往是由好多组件组成的。Page = ComponentA + ComponentB + .....。而一个组件的UI = Fn(props, state)，Fn就是组件本身代码。而保险的页面基本都是千人千面输出的，尤其是其中一些运营类模块，如红包弹屏、营销banner等等。

一般来说，组件的state往往是处理一些业务逻辑的内部状态，核心决定组件UI的就是组件props。所以大部分套路就是：页面的根节点组件，从某一个千人千面的数据服务获取各个组件的配置化props，再分配注入到各个组件，最终渲染出千人千面的页面。

那么问题来了，对于这类需要千人千面运营的页面，如何去抽象组件，如何跟某个数据服务关联，如何做到跨页面快速复用与投放？

最终我们这边实现了一套智能组件方案，在传统组件之上融合了千人千面的数据推荐服务，实现组件的可视化运营配置与快速投放。

智能组件演示

智能搭建

很多公司都有自己的搭建服务，蚂蚁也有一个建站服务-云凤蝶。其对内支持移动建站的版本叫闪蝶。它支持开发组件与模板，然后运营在模板中选择自己想要的组件，再配置组件需要的props，最后构建出自己的移动站点。保险基于这套能力，也输出了大量的营销站点。

但这里存在一个问题，用闪蝶服务去配置的props，是静态写死的。没法像我上面智能组件中提到，可以根据不同人群等规则去做千人千面的数据配置。

所以我们又基于闪蝶底层服务，融合我们智能组件的能力，实现了一套千人千面的搭建服务。

有了这样的能力以后，我们的运营就能直接搭建出精细化运营的营销页面了。

智能相机

相机在前端领域，大部分功能就是用于拍摄用户的一些信息材料，获取后上传。而在保险业务，这样的场景有非常多。比如：

车子受损了要定损，通过相机拍取车损画面，简单判断车损级别。
理赔服务时，通过相机拍取病例、医疗费用单等信息。
宠物险，通过拍取宠物狗鼻纹，获取宠物唯一标识，做宠物核身。

但这些画面的获取其实没那么简单的，用户拍上来的信息大部分情况质量很差，这就需要在端上做智能引导，这就涉及一些机器学习跟相关演算法。在之前，演算法引擎这块都是客户端团队来做的，但是严重依赖于客户端发版，而且跨端能力弱。从19年开始，我们基于Tensorflow.js，把演算法引擎跑在浏览器端，并做了大量性能优化工作以及配套的中台服务，最终实现一套支持跨端与快速迭代的智能相机研发体系。

智能相机演示

工程效能

小程序React研发框架-Remix

Remax 可能大家有听过了，其实在同一时期，我们的相互宝业务线，也诞生了一款支付宝小程序React研发框架-Mars。相互宝是保险第一款支付宝小程序，但确实研发范式上，跟蚂蚁的React体系显得略有偏差。为了提升研发效能，我们的技术同学也研发了一款更面向内部的研发框架。当然跟Remax确实还是有不少重复，所以目前我们的Mars跟Remax进行了合并，合并后对外品牌名依旧为Remax，对内为Remix。现在保险的支付宝小程序已经可以基于React去愉快的开发并耍起hooks了。

Cod：BFF体系下的LowCode解决方案

蚂蚁大部分C端业务目前基本都是基于BFF（backend for frontent）体系。bff这套体系，让前端可以掌控controller层，使得后端可以专注于领域模型，前端可以更好地面向页面端提供数据。但也存在一些问题，很多场景下，数据流转与处理其实没那么复杂，bff变成了一个透传层，但是配套的要写很多模板代码，如一些基础的单测、监控等等，这反而是降低了整体效能。

那有没有办法进一步提效呢？Cod应运而生，我们做了一套代码编排与服务编排的能力，可以在C端通过类似GraphQL的方式直接消费与编排后端提供的远程服务。

小结

除了上面提到的，我们业务上还有商业险中台体系、技术上还有基于Electron实现的联调工具等等，具体就不多细讲了。

整体而言，保险还是紧贴业务诉求跟工程效能，做了不少技术建设，基本involve了所有的前端同学。大部分同学都能随著业务发展有自己的技术成长。然后这些技术建设，确实也比较贴进阿里经济委员会提出的一些方向。如智能化领域，我们有端智能上的建设；搭建领域我们有精细化营销页的搭建建设；cod带来的服务编排与代码编排能力，广义上说也是属于serverless领域等等。

说实话，我们做这些事的时候，确实也没想著贴著什么方向，不过走著走著确实也是这几条路。不得不说，大佬们还是非常的高屋建瓴的。

招聘

说了这么多，一小方面是给大家提供一些参考，更大一方面还是希望能吸引到业界的优秀人才。

目前蚂蚁保险业务上，发展势头强劲，是未来蚂蚁增长的新一代发动机。而且互联网保险依旧处在较为蓝海的阶段，很多事项都还在0-1建设，存在非常多的机会与可能，亟需优秀的前端人才

技术团队上，目前团队规模40人+，含若干个前端小组。纵向上，进行业务规模化、专业领域化小组分工，如我这边是用户增长小组。横向上，成立各类虚拟技术小组，大家可以挑选感兴趣的技术方向深入学习与探索。

整体而言，业务发展好、技术牛人多，未来清晰、成长可期~

具体招聘要求，也不长篇大论了。总体而言：技术上基础扎实、某领域深入（Node/互动营销/搭建/端智能等等）；学习上善于沉淀、持续学习；性格上乐观开朗、活泼外向。

招聘层级：P6-P8

如有想法，可投递简历到邮箱：[email protected]

也可以先发个微信过来，我加你再做细聊~

团队照片

最后补一些我们日常的一些学习、生活、娱乐照片。

周会讨论与分享

偶合喝喝小酒

遇到开心事去城市阳台体验下Expensive Life

可爱的妹子们

喜欢结对编程

没事儿玩玩密室

最后帅哥镇楼，希望再多吸引点儿妹子

坐标天津，小公司，目前前端团队只有 3 人。

19 年刚来公司的时候，当时前端只有一个人，而且还是用 JSP 写页面。所以我当时的目标是要把前端往工程化方向发展。虽然前端团队没几个人，但还是希望团队能跟上时代的发展，别落后太多。

截止到目前，我到公司已经一年了，这一年我们的前端团队做了以下事情：

彻底抛弃 JSP，所有的项目都是前后端分离。
统一开发工具，统一编码规范（利用 VSCode + ESlint 自动格式化代码），统一项目规范，统一 UI 规范，统一 GIT 规范（分支管理、commit 规范等等）。
使用 Vue 技术栈。
所有的公共组件，工具函数必须写单元测试。
由于公司的主要业务是写后台管理系统，业务页面大部分都有相似之处。为了提高开发效率，开发了一个业务页面模板生成器，可以根据配置文件生成半成品业务页面，在此基础上再进行二次开发，大大提高了业务页面开发速度。
性能优化。
鼓励技术分享，公司内部有专门的 wiki 知识库，鼓励大家将一些心得、经验写成文章分享。
有空时研究新技术，看是否能在公司项目上落地，例如最近研究的前端可视化开发。

虽然这一年做的事情不怎么高大上，都是很基础的事。但是切切实实地提高了前端开发效率以及前端标准。尤其是在规范化这一块上，作了很大的努力和改进，对我们的帮助非常大。

今年要做的事情：

希望在一些长期项目上实行前端监控（性能监控和错误监控）。
使用多个技术栈，考虑 React 或 Angular。
推行 TS。
推行 mock。

最后，推荐一下自己，北京或天津有缺前端的吗？

从另一个问题过来（2020年前端最火的技术是什么？），发现很多答主都提名了「Serverless」。如今的 Serverless 可以说是一大有潜力的新技术方向，尤其在当下上云的热潮中，Serverless 因其免运维、自动扩容、支持多种编程语言等优势，对前端来说，是一大提升服务开发、维护效率的利器，也是可尝试全栈发展的方向。

但也因为其新，对落地到团队开发中，结合团队开发流也是遇到了一些挑战，恰巧 IMWeb 也在这方面有过尝试，遂分享。本文作者： @Enjoy Chan

一、IMWEB 团队 Serverless 研发模式的演进与思考

在过去一、两年，我们团队在多个服务项目中尝试使用 serverless，腾讯云 Serverless 提供了一站式服务，通过使用该服务，前端可独立完成介面服务开发，对前端个人而言可往全栈发展，也因此可缓解团队后台人力紧张问题

在开发 Serverless 云函数的过程中，我们也遇到了对比传统服务，云函数开发的一些挑战点

（1）云函数开发特点

前端传统项目的开发流模式相对已经比较成熟，通过 git 协同管理代码，再通过 CI 来规范项目的部署流程，整个工作流可以查看、回滚代码，部署也做到了自动化

再来看云函数的开发特点：

云函数独立的账号和许可权管理
以函数为单位进行创建、更新和部署
创建网关 API 与函数关联，借此可通过网关 API 访问到云函数

以上是最基础的开发云函数三个基础

而云函数的创建、更新有两种方式：

腾讯云官网云函数控制台，可视化的操作界面，点击按钮即可创建、更新
通过 CLI 创建，SERVERLESS 提供 SDK，调用 SDK 可完成自定义创建、更新操作，其优点为灵活编写，也易于做成工程化

考虑团队的协作，第二种方式通过调用 SDK 的方式因其灵活更适合定制为团队规范

总结下来可以看到云函数开发的三个特性：

因其有独立于 git 账号的云函数账号，导致了云函数的代码缺乏像 GIT 一样可以查看历史代码版本，代码修改记录等
因其有多重方式可以用来创建、更新函数，导致多人协作时，有互相覆盖云函数的风险
提供的云函数网关，可帮助快速配置访问云函数，而无需运维同学帮忙做域名指向，机器申请等

（2）团队协作上手云函数开发问题

在初期团队探索尝试云函数开发时，对比传统项目的开发流，云函数的开发步骤更多，也暴露出了一些缺点：

1) 上手成本高

首先有不小的学习成本，像云函数配置文件，云函数官网界面操作学习成本，实际使用时，由于云函数网关 API 链接过长、域名限制等，需要配置 nginx，用特定域名访问云函数网关 API，因为多数前端对 nginx 部署，导致有了 nginx 学习成本

2) 调试云函数效率低

因为云函数是部署在云端的，Serverless 有其独特的环境，context、event 等，有别于 NODE 服务的请求体等，本地要完全模拟 serverless 请求比较困难，导致开发想要调试定位问题时，只能先将代码部署到 serverless 上，这里就需要等待部署了，由于 serverless 是外网的，部署时间就更长了

3) 开发流困惑

由于云函数直接就是部署在云端，没有我们传统的机器用于做环境区分，对团队协作保证部署质量来说并不友好
上述也有提到的，往往因为想要自己业务域名访问服务介面，而云函数网关 API 是比较长的缺乏语义化的链接，通常使用时会想配置 nginx 去通过自定义域名访问云函数，不止是成本问题也有容易配置错误的风险问题

4) 管理困难，存在质量问题

因云函数独立的账号管理，没有 git 进行管理，导致无法追踪代码记录，甚至任何有许可权的人创建同名函数进行部署都会导致函数莫名被覆盖，同理云函数网关 API 也可以随意更改指向其它云函数

总结下来，在团队协作 SCF 开发的时候，遇到的挑战点如下：

二、IMFLOW 一站式 Serverless 开发解决方案的破局与落地

总结上面的云函数在团队协作中遇到的一些问题，对应地提出解决方案：

制定规范保证统一的协作，统一的规范保证统一的工作流，提升开发效率进而保证质量
优化云函数开发体验，通过工具去自动化完成重复冗余的操作，并通过封装过滤掉一些开发学习成本
根据云函数特点制定 CI 和 CD，保证流程统一，也提升部署效率；统一网关规则，减少云函数网关 API 学习和操作

（1）制定规范，提升协作效率

1）统一云账号管理

对于独立云函数账号，每个开发在上手开发前都需要单独申请，同时还有开通各种许可权，快点半天，慢点一两天，针对这个问题，考虑使用团队公共账号进行统一云函数管理，工具使用公共账号进行云函数部署、更新，免去开发的学习成本、账号上手成本

2）基于 GIT 管理云函数

对于云函数独立的管理方式，为了能唯一追踪云函数，保留了原有的 git 管理项目代码，制定一系列规范，将 git 项目与云函数唯一关联，保证云函数唯一不可覆盖

3）命名空间隔离函数环境

为提供云函数的开发流，针对云函数的特点，使用云函数命名空间的概念来隔离云函数，同时限制测试环境的网关服务只允许内网访问，保证业务安全

4）统一云函数规则配置

制定云函数名、对应网关服务 API 名、环境命名空间的命名规范，以达到命名空间、函数名、网关服务 API 能一一对应，可通过其一推导其二，如知道函数名，可知其访问 API 是什么，对应环境命名空间是什么

（2）自研 CLI 工具， IMFLOW 提升 SCF 研发效率

在第一项制定了规范之后，要让规范落地，就需要使用工具来辅助，IMWEB 团队自研了 CLI 工具 -- IMFLOW，提供 SCF 团队开发流实践方案，通过工具的方式提升 SCF 研发效率；诸如创建账号、申请许可权、创建云函数、开发云函数调试、云函数网关 API 关联、函数隔离等等，通过 CLI 工具，输入命令即可完成。

1）上手开发更快

使用了 CLI 工具来辅助之后，对比团队过往的开发模式，通过 CLI 可达到 2 分钟上手进入开发

2）调试体验同传统服务开发一致

通过同构 + 构建的方式，保留传统服务开发体验，工具封装屏蔽了云函数文件，开发者开发时可同以往一样

3）一键定位调试云函数

云函数的真实运行环境相对复杂，若是遇到了涉及云函数环境调试的问题，需要真实调试云函数，此时本地即可完成调试，工具封装了一系列操作，如实时调试、监听文件变更等，实时部署，实现一键定位调试云函数

4）极致优化云函数部署时间

云函数的部署是走的外网部署，而云函数的部署时间影响到了云函数的发布时间，甚至在做本地实时调试云函数时，影响了云函数的调试效率，为了极致优化云函数部署时间，利用了云函数的 layer 功能、项目的 node_module 变动几率较小、同时代码包大小会影响部署时间这些特点，对云函数项目部署进行了拆分，当 node_modules 没有变动时无需部署 node_modules，进而减少了了部署时间

在做了部署优化后，查看项目的部署时间，大部分时间 35s 即可完成函数部署

（3）质量保证

在质量保证方面，主要是通过 CI | CD 规范部署流程，制定网关服务规范来隔离云函数和降低网关配置成本。

限制测试环境网关服务为内网可访问。

另外，为了保证云函数的运行稳定，避免因为云函数的冷启动导致云函数访问失败，即对云函数的容灾处理，做了一层 STKE 的容灾，通过代码同构的方式，利用工具构建打包，完成一套代码实现既可部署 serverless ，也可以部署 STKE，配合网关的处理，完成云函数的降级容灾

三、IMFLOW 使用

imflow 内置命令

至此，感谢阅读。

Serverless 架构应用开发京东￥ 318.00去购买?

相关回答：

什么是云计算？?

www.zhihu.com

CDN是什么？使用CDN有什么优势？?

www.zhihu.com

2020 国内公司前端团队都在搞些什么?

业务情况

技术事项

营销与运营体系

智能组件

智能搭建

智能相机