我们是蚂蚁保险前端团队，我们今年在做什么？

2020/6/23 11:27:48

编程Tag： 招聘

本文主要是介绍我们是蚂蚁保险前端团队，我们今年在做什么？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

前不久在知乎上看到一个问题，《2020国内公司前端团队都在搞什么？》，背后其实是好多前端同学对未来的迷茫。在前几年，前端突飞猛进，很多新技术接踵而至。虽然大家口口声声说学不动了学不动了，但大家至少有个目标可以去学。

五六年前，学个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，把算法引擎跑在浏览器端，并做了大量性能优化工作以及配套的中台服务，最终实现一套支持跨端与快速迭代的智能相机研发体系。

掘金无法播放视频，智能相机相关视频可到语雀看查看：www.yuque.com/wuomzfx/uxz…

工程效能

小程序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领域等等。

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