从考拉前端团队演进看前端技术的变化与取舍

2015 年，考拉前端团队只有 6 个人，到 2019 年年底，这个数字已经变成了 100。随着团队人数不断增加，技术和管理上的挑战也会接踵而来。如何分阶段建设前端团队？前端团队如何分工？随着前端技术快速更迭和业务不断变化，前端团队如何做到快速重组和调配？InfoQ 记者有幸在GMTC 全球大前端技术大会（深圳站）2019上采访到了考拉海购前端负责人俞棋军，他与我们分享了自己在建设考拉前端团队过程中的一些思路，对于前端技术的发展现状和未来，他也提出了自己独到的见解。

考拉前端团队演进

作为最早的团队成员之一，俞棋军见证了考拉前端团队从最初的 6 个人，在五年间增长到百人左右。他与我们分享了考拉前端团队在技术和管理模式上的演进过程。

2015 年左右，考拉在大促 PK 中得到了非常大的业务反响，这意味着考拉从最初的产品原型到业务实现迈出了很重要的一步。从这次大促 PK 以后，基本上建立了考拉一个月一次大促一次小促的运营模式，这种模式给当时只有 6-7 个人的前端团队带来了非常大的考验，因为很多运营工作、大促页面搭建需要在前端完成。团队一开始只在 PC 上做活动页面，到五六月份投入手机 APP 的开发中，很多流量开始导向 H5，那也是移动开发快速发展的黄金时期。

2016 年底，原有的搭建模式已经难以继续支撑业务场景，H5 搭建退出历史舞台。考拉前端团队和客户端团队共同决定转向 Weex 跨端解决方案开发。虽然 Weex 号称在 iOS、H5 和安卓端都通用，只需要一次开发，但实际应用后团队发现依然有一定的开发成本，因此在解决各个端的适配性问题上投入了不少额外的工作量。

2015 年到 2017 对应的是考拉前端团队从 0 到 1 的建设，2018 年以后则是从 1 到全家桶的过程。2018 年左右，团队开始做部分监测工作，包括用户在站点上的购买体验优化、性能监控和端上的离线缓存。2019 年则是进一步深化离线方案、BFF 建设、跨端建设以及页面性能监控等的落地，中间还完成了前端统一部署平台的开发。

俞棋军认为，如果团队的技术栈、工程化工具、部署平台确定了，开发人员在不同业务之间切换的时候成本应该是很低的，而降低切换成本的核心是要把前端团队的基础建设做好，包括标准化、统一化的工作，这是 TeamLeader 应该要关注的问题。

2019 年 9 月，阿里宣布收购考拉，除了继续维护日常的业务工作，考拉前端团队投入了不少人和精力在技术迁移工作上，包括网易侧的切除和阿里侧的引入。

除了技术侧重点的变化，团队不断壮大也会带来管理上的挑战。到 2016 年，考拉前端团队成员已经从一开始的 6-7 人增长到了 20 多人，后面几年也基本按照每年 20 人左右的速度扩增。据介绍，随着技术的更迭以及业务需求的变化，考拉前端团队的管理模式经历了从单一职能团队变为拆分到各事业部再到重新形成职能矩阵的演进。

一开始，由于考拉内部业务越来越多，而前端开发又是职能属性非常重的角色，团队根据业务线作了比较细的拆分，如果横向有需求再在各个业务线上做人员调度。但完全拆分到事业部的管理模式也带来了一些问题，单纯以事业部的业务为目标，会导致在做一些横向调度和基础工作推进时，工作无法有效展开或推进速度较慢，尤其是工具的普及、升级和公共平台的建设等。因此后续团队管理模式又回到了职能矩阵的形式，按照前台、中后台、运营工具、公共技术等分工。

俞棋军认为，针对不同规模的团队，TeamLeader 在管理上相应地应该有不同的侧重点。以他自己为例，考拉的发展过程基本上就是一个业务驱动的过程，因此刚开始 TeamLeader 更多还是以业务导向的方式来做管理。很多技术工作会被业务倒逼着走，业务在不停地增长，但技术人员没有跟上，还是陷在原先的开发工作中，当时俞棋军的工作只能是消化业务、招人、消化业务。但是仅仅是招人消化业务根本做不好团队梯度建设工作，因此到后面他转变了工作思路，更侧重于解决团队梯度建设问题，把团队核心人员放在核心岗位上，如果有能向 TL 发展的就向 TL 培养，如果没有就去外部招聘特定人才，重点要将团队的腰部力量建设好。

性能监控是重中之重

过去一年，考拉前端团队主要围绕页面性能监控、跨端、离线化方案这几个大的技术方向展开工作。

以监控为例，由于很多页面跑在线上，如果没有监控，开发无法感知到这个页面在端用户这边跑的情况到底怎么样，所以长久以来，其实前端对自己开发的页面线上的运行情况是无感知的。在 18 年以后，考拉前端团队将监控放在了比较重要的位置，基本上线上错误、线上业务都能监控起来，对线上的性能也展开了从 0 到 1 的建设。借助性能监控，找到页面性能短板，再引入相应的提升性能的解决方案，比如通过离线缓存来优化页面打开时间、SSR 相关工作等。

此外，考拉前端团队也是 Weex 的深度用户，在跨端建设方面积累了一些经验。考拉前端团队的 Weex 开发分为两大块，一块是客户端 Weex 自建，另一款是前端业务端的建设。俞棋军表示，Weex 开源的第一个版本内部的坑非常深，由于考拉在 Weex 上进行一次活动搭建最多可能需要展现 100 多个屏，对客户端性能要求非常高，所以客户端和前端同学在使用过程中踩过了不少坑。比如他们曾在 Weex 方案上引入多团队参与模块开发的时候引发了上线部署的一个效能问题。由于负责社区、会员、内容等不同模块的开发人员都要基于 Weex 共同开发自己的业务组件，当要上线的时候，开发会先上线核心开发模块，再上线会员的搭建模块，如果前面的搭建模块出了问题，后面的业务就没办法上线了。这样的相互依赖会导致团队间的发布效率低下。

为了解决这个问题，考拉目前采用了阿里集团内部的一个解决方案，把每个模块开发放在工程外，开发人员在开发完这个组件发布到线上以后，在搭建平台里把这个模块配置进来，运营就可以使用这个模块了。这样的话，不再像原先 ABC 三个模块都在搭建工程上开发，然后三个业务方开发，现在 ABC 分别在其他平台上开发，发布完然后在搭建平台上配一下，这个模块就可以用了。这样就不会再有上线相互依赖阻塞的问题了。

前端技术趋于统一和标准化

回顾前端领域的 2019，俞棋军认为这几年前端技术更多还是在吃原先的老本。Vue 3.0 和 React 新版本在俞棋军看来都还是“原有的味道”，他表示，在现在的发展趋势下，技术栈越来越统一，所有团队都在两个技术栈上做选择，技术栈的一些解决方案也是在原先的生态上延伸出来的，目前并没有看到这个领域冒出很好的独立的新技术。

“Flutter 其实几乎不太会在前端领域普及起来。”俞棋军补充道，“Flutter 是 iOS 端和安卓端的一个跨端方案，但是要把前端原先的标签化开发模式转换成对象开发模式，对 H5 的开发来说其实是一个历史的倒退。因为开发模式完全不一样，在 H5 上开发用标签化的开发模式就可以了，但是到了 Flutter 上没办法用标签语言来写，必须要罗列对象才能做出一个页面，还需要考虑 H5 的兼容性、性能等问题。目前位置，Flutter 的整套开发解决方案在 H5 上没有竞争优势，对于 H5 的开发来说，如果他们的开发模式迁移到 Flutter，会变得非常别扭。不过话说回来，用 Flutter 来做端上的应用开发是比较 OK 的。”

对于目前前端领域非常火爆的 Serverless，俞棋军认为需要根据企业自身的情况来判断其价值。在他看来，Serverless 首先是一个胶水层，它是把后端的某几个服务糅合起来，形成一个 API，输入给网关，前端的工程通过网关把胶水层黏合起相应服务的数据拿给前端。这其中存在两个问题，一个是，服务端的服务是否足够完善，或者中台服务是否足够完善。如果一个业务的中台服务足够完善，那直接通过 Serverless，把原先的服务编排一下输出接口给前端应用，确实对于效率提升非常快。但是大部分的中小公司并没有这么完善的中台服务可以用，很多时候一个开发任务，前端、前台、中台、底层数据库都要一起开发，如果在这样的一个开发过程中，再加上一个 Serverless 的开发环节，对整体工作效率的影响不是提升，反而是降低了。

俞棋军表示：“Serverless 在监控日志足够完善的情况下，在公司范围内，对前端领域的扩展还是有比较大帮助的，前端人员会更多地渗透到业务当中去，而且在整个团队的运作效能上也是有帮助的。但对于中小型公司或大公司的新业务线，服务没有这么完善的情况下，用 serverless 并不一定有帮助，我是这样的一个观点，因为我们团队也是这样的一种应用场景。”

据了解，目前考拉在客户端有运用 Servesless，但用的很少，目前只有两个接口在用。不过俞棋军也透露，等考拉迁入阿里以后，Serverless 肯定是会考虑进去的，应该会大面积用起来，因为对于整个阿里集团来说，服务已经足够完善，Serverless 确实能够提升团队的运作效率。

展望未来大前端领域技术的发展趋势，俞棋军主要提到以下三点：

1. 2020 年随着 5G 的普及，页面加载会更快，手机端 H5 的呈现性能会更高。

2. 未来前端肯定是越趋标准化的一个工作。无论是开源工具也好，开源组件库也好，还是说开源的技术栈，都会逐步标准化。就算不是在 2020 年，到了 2021 年或者再往后，整个前端的工作都会标准化。现在可能有多个解决方案，但最后可能是某个解决方案的开发体验好、业务产能价值大，这个解决方案最后会被大量采纳，就会保留下来。

3. BFF 正在被淡化，更多的是用静态工程部署，而不是通过 BFF 跑在 Node 上来做工程部署，随着 Serverless 的发展，这个趋势也比较明显。静态部署的开发体验好很多，如果工程放在 BFF 上开发，前端开发不但要在静态工程上开发核心业务，还要在 BFF 上做一些接口层的转发或者接口层的糅合。最理想的情况是静态工程做完了，Serverless API 编排上来了，静态工程一上线，服务全都打通，这样开发就会更平滑，开发的体验会更好。

采访嘉宾介绍

俞棋军，考拉海购前端负责人，2005 年毕业于浙江大学软件学院。2009 年入职网易杭研院，从事前端开发工作，参与的项目有网易博客、秀品、网易机票、易信 Web 版等。2013 年梳理前端技术体系的相关内容，给公司的前端团队做技术培训，参与制作早期的网易教育前端课程。2015 年参与到考拉的前端建设中，从考拉最初的 6 人团队，一路建设到 100 人左右的前端团队。现在他在考拉的业务建设主要分为两部分，一是从 0~1 的建设过程，二是从 1~全家桶的过程，包括离线方案、BFF 建设、跨端建设以及页面性能监控等落地。