从阿里前端工程化中台实践，看中台建设的舍与得

作者|朱华军（阿大）

出品|InfoQ&阿里巴巴新零售淘系技术部

导读：随着前端技术不断从 Web 延伸至各种“端”，大前端的概念早已成为业内共识。伴随着大前端的发展，与之相对应的前端工程体系也在不断拓展边界，仅仅只是构建、工具和规范等常规方式已经不足以表达当下前端工程所涉及的领域。

嘉宾介绍：

朱华军（阿大），阿里巴巴淘系技术部高级前端技术专家。2009 年加入淘宝网，负责过淘宝交易、商品等基础业务及机票彩票、一淘等创新业务。2013 年开始专注于前端工程化领域，推动开发工具、流程和规范的统一，完成淘宝近百人前端团队研发模式的整体升级。目前负责阿里集团前端工程化中台的建设。

前言：

近日，阿里巴巴高级前端技术专家朱华军（阿大）受 InfoQ 采访邀约，分享了阿里集团前端工程化中台的实践过程，以及实践背后的经验与思考。他在采访中强调，前端工程化一定是大趋势，但不建议大家盲目地追求工程化，对于大部分规模不大的前端团队而言，工程体系的建设和规范并不是当务之急。

接下来，阿大将在 QCon 全球软件开发大会（北京站）2020 担任大前端大工程专题出品人，为大家带来各大厂前端团队在工程领域不断拓展思路、换道创新中沉淀下来的经验和实践，感兴趣的读者可以关注。以下为采访问答实录。

---

Q：您从 2013 年开始专注于前端工程化领域，并完成了淘宝近百人前端团队研发模式的整体升级，能否先总体介绍一下淘宝前端团队研发模式的发展历程，期间一些重要的节点。

朱华军（阿大）：

我是 09 年加入的淘宝，那时淘宝前端的研发体系还比较原始，代码管理是基于 SVN 的，所有前端代码都在一个代码仓库里。每周有两个发布窗口期，SCM 会提前拉好开发分支，大家在一个分支上开发、集成和上线。那个时候前端的代码是所写即所得，不需要编译构建什么的，本地的开发环境相对也简单，基本以文本编辑器为主。

大概到了 13 年的左右，NodeJS 和 Git 开始流行，淘宝前端联合 SCM 团队基于开源的 Gitlab 在集团内搭建了 Git 托管环境，前端是最早将代码从 SVN 全部迁移到 Git 进行管理的技术岗位，这个决策对后续阿里巴巴前端工程体系建设起到了非常重要的影响。由于 Git 在分支管理特性上的优势，原先前端的集成开发模式慢慢演变成了基于 Git 分支和 Gitlab Web Hook 的半自动化模式。

另外 NodeJS 的崛起也快速促进了我们内部前端本地开发工具生态的完善，各种本地 Command Line 工具如雨后春笋般涌现。百花齐放的繁荣之后必然的结果就是规范和一统，彼时刚好集团在推行中台战略，前端研发工程体系顺势走上中台化道路。

Q：集团内部是什么时候确定要做前端工程化中台的？做这个决定的背景是什么样的？面临的最大挑战是什么？期望中台解决什么问题？

朱华军（阿大）：

17 年初的时候吧，在这之前我们已经统一了淘宝前端团队的工程体系，有了完善的本地开发工具生态，标准化了本地的开发和调试。另外还搭建了一套在线发布流程，孵化了如云构建（代码在线构建）、门神（代码静态扫描）等前端工程基础设施。

那一年初团队在做规划的时候，大家对前端工程体系接下来发展方向有一些争议：

• 第一个观点认为我们应该将本地的研发工具统统搬上云，包括在线 IDE、在线 Dev 等，在线化一定是未来的趋势；

• 第二个观点认为我们应该输出淘宝前端的工程能力到整个阿里巴巴集团，淘宝前端的工程体系建设已经站在了集团的制高点，应该顺势推进整个集团前端研发体系的规范化。

在当时的情况下，集团中大部分 BU 的前端体系或多或少都源自淘宝前端，中间有着千丝万缕的关系，另外还有一个外部因素就是大家已经非常熟悉的阿里提出的中台战略，在集团中台战略大的趋势下我们最终毅然决然地选择了建设阿里巴巴前端工程中台。

当然这不是说第一件事情就不重要，恰巧在经历过前端工程中台的建设后，我们目前在做的就是 IDE 和在线研发能力。

阿里是一个庞大的经济体，各事业群和事业部加起来有几十上百个大大小小的前端团队，推进如此多的团队来规范前端研发体系的阻力是巨大的。加之每个前端团队当下的前端工程体系建设程度不一样，对标准化前端工程开发的理解和需求也都不一样，如何说服并协调推进如此众多的前端团队，是我们做这件事情遇到的第一个难题。

简单说下我们是如何解决的，类似的问题我想稍微有规模一点的跨团队协作项目应该都会碰到，我们首先 需要得到自上而下的支持。阿里巴巴集团内不同的技术栈都有一个技术委员会，前端也有一个阿里前端技术委员会。技术委员会的成员一般都是各事业群较大规模前端团队的 Leader，每年委员会会发起几个技术项目，并协同集团内资源合力推进。经过努力，前端工程中台争取到了委员会其中一个技术项目。有了自上而下的支持，很多事情推进就方便多了。不过光靠自上而下推动也是不行的，毕竟技术体系的升级改造对日常业务的正常进度肯定是有影响的。

另外 对于大部分规模不大的前端团队而言，工程体系的建设和规范并不是当务之急。所以我们首先选择集团内规模最大的 TOP 5 前端团队进行推进，这些团队对于规范前端研发的需求更加强烈，并且本身也有一定的工程底子积累，沟通可以更加顺畅，彼此之间也有更多的理解和认可。当几个较大前端团队统一之后，其它团队就轻松很多了，甚至大部分小团队是主动要求接入前端工程中台的。

大部分的基础技术体系建设逃不开三个关键字：效率、质量和成本。前端工程体系的建设也是紧紧围绕着这三个关键字，通过标准化的研发能力和统一的流程规范来约束研发过程中的不确定性，从而提升研发效率和质量。效率和质量提升了，成本自然就降了。而前端工程中台的目的是期望降低所有前端团队达成这一目标的门槛，不管团队在什么阶段、是何种规模，都能借助前端工程中台快速落地适合自身组织形态和技术特点的前端工程方案。

Q：阿里前端工程化中台能够提供哪些服务和技术能力？在通过中台提高前端研发效率上，能否列举一个具体示例进行说明？

朱华军（阿大）：

在我个人的理解里，标准化和开放一定是任何一个中台必须具备的能力。这两者看上去似乎有点矛盾，却是我们在建设前端工程中台时切实的感受和总结。比如我们统一了静态源站和发布流程，规范了本地工具命令入口和装载更新模式，更是推进了标准化的在线构建体系与代码检查体系的建设。关于开放，前面有讲到前端工程中台的目的是降低所有前端团队工程体系建设的门槛，所以赋能必然是中台的使命之一，开放是赋能最直接有效的方式。

完善的工程体系必然会帮助团队提升研发效率，而工程中台的使命是帮助每个团队更高效的完善工程体系的建设。对于中台而言，研发效率的提升其实并不是最直接的收益，而是全局性的收敛和管控能力。

我举个收敛管控方面的例子：18 年集团整体推进安全生产策略，所有的线上变更必须接入统一的变更管控平台，提交变更单后允许进行线上变更。这个时候工程中台的价值就体现出来了，因为我们已经经过一年多的努力收敛了所有前端的发布流程，整个集团所有前端的发布接入统一变更管控几乎没有成本地实现了，这在推进前端工程中台之前是无法想象的，如果没有前期的收敛根本无从下手。

Q：阿里前端工程化中台目前推进情况如何？与您的预期相符吗？您理想的状态应该是什么样的？

朱华军（阿大）：

目前的整体进展还是比较符合预期的，在流程规范和标准化方面我们已经取得了非常好的效果，并且在推进工程中台的实践过程中积累了不少优秀的能力平台，这些都是宝贵的资产。

当然等着我们去做的事情还很多，有两件事情是我们后续的重点。第一件事是开放的 IDE 生态建设，经过大半年的封闭开发我们已经完成了代号为 “开天” 的 IDE Framework 的研发，IDE Framework 是 IDE 的核心，通过 “开天” IDE Framework 构建的各种 IDE 实现（Web 或本地）来打通研发生态。待再进一步完善后，我们将开源整体的 IDE 解决方案，包括开放的扩展生态体系、Web IDE 容器侧能力等。未来阿里前端的工程体系一定是围绕着 IDE 展开的。

第二件事情跟开放相关，目前我们所有的工程能力都是服务于内部员工的，我们期望借助阿里云能够以平台化、体系化和产品化地方式输出阿里的前端工程实践，服务社区服务行业，为推进国内前端的发展出一份力。

Q：在前端工程化中台推进过程中，来自前端团队的反馈是什么？有没有遇到什么困难，你们是如何解决的？

朱华军（阿大）：

困难肯定有，前面也有讲到，在阿里巴巴如此庞大的体系内，多部门的协调和落到遇到阻碍在所难免，关键是找到正确的解决方法。在每个前端团队中，对于工程化带来的收益在个体与团队整体的体感差异是很大的。

这个怎么理解呢？我在很多场合表达过，越是完善的工程体系对个体的约束往往是越强的，带来的结果可能是个体的效率反而是下降。所以我们在推进工程中台时，来自一线的反对和抱怨声是蛮常见的。但如果我们换个视角，从团队整体的角度去看待效率这个问题，一定是能达到 1+ 1 大于 2 的效果的，特别是规模越大的团队效果越明显。所以在前端工程中台的建设和推进中，我们优先考虑的都是如何帮助团队整体获得更高的收益。

Q：您认为前端工程化中台是大势所趋吗？推进过程中可能还会遇到哪些挑战？

朱华军（阿大）：

前端工程不是万金油，它是在特定场景及特定时期的针对性解决方案，越是完美、越是高效的工程解决方案越是被所服务的组织结构和技术架构所约束，所以对我合适的前端工程解决方案对你未必合适。

前端工程化一定是大趋势，但不建议大家盲目地追求工程化。任何体系或平台的建设都是需要投入成本的，还是要结合自身组织特点，先清楚地认识自己所处的阶段，计算清楚投入产出比。

• 如果是 10 人以下的小规模的团队，适当制定研发规范即可；

• 10 - 30 人规模的团队可以制定一些研发规范、落地工具和流程；

• 30 人以上团队规模就要开始体系化思考前端工程能力的建设了。

中台亦是如此，不要为了中台而中台，先想明白要解决什么问题。

Q：机器学习在大前端领域也正成为一项越来越重要的技术能力，阿里前端团队在智能化方向上还有哪些探索工作？您如何看待前端智能化的现状和未来发展？

朱华军（阿大）：

阿里前端布局机器学习领域相对较早，前端智能化体系建设已经连续两年作为经济体前端委员会的技术项目之一了。并且也已经有了相关的成型产品：imgcook（https://www.imgcook.com/）。imgcook 基于大数据机器学习，可以智能地将设计稿转换成前端代码，在 2019 年双十一开始就已经大量应用到会场页面的开发。还原精度业界领先，并且支持自定义扩展 DSL，大家有兴趣可以访问官网详细了解。

基于机器学习的智能化辅助开发是前端领域的下一个技术风口， 我所知道的国内国外不少大公司都在做。这个领域在基础技术方面的发展已经比较完备，不过目前前端在这方面的人才储备还非常不足，有兴趣的前端同学可以多了解了解。

Q：您将在本次 QCon 北京 2020 上担任“大前端大工程”专题的出品人，能否跟我们详细谈谈所谓“大前端大工程”指的是什么？这个专题将会跟大家重点分享哪些内容？

朱华军（阿大）：

大前端的概念应该不需要过多介绍了，传统的 HTML、CSS 和 JS 已经完全无法定义当下的前端。大工程其实是跟大前端相对应的，仅仅只是构建、工具和规范等常规方式也已经不足以表达当下前端工程所涉及的领域。为了提升研发效率、为了保障大规模协同、为了激发业务创新，各大厂的前端团队在工程领域不断拓展思路，突破界限；优秀的初创企业也从中另辟蹊径，换道创新。如此繁荣的前端工程生态也只有叫大工程才配得上了。

本届 QCon 该专题将遵循 “大前端大工程” 的定位彻底打开前端工程实践领域，我们会邀请国内各大厂的优秀前端团队来分享如何通过创新工程等手段来解决极限业务诉求。除了实践之外还会有几个前端工程相关的基础技术（Webpack 等）分享，这块以海外嘉宾为主。

Q：大前端领域涉及的工程能力越来越多样化、复杂化，这是否意味着前端将进入一个新的阶段？前端工程师如何做好准备？

朱华军（阿大）：

其实前端一直在不停的进入新阶段，“学不动了” 这个笑话很好地阐释了前端技术领域的迭代变化之快。我认为工程能力的完备程度，可以非常直接地体现一个技术的成熟度。完善的工程能力必然催生工作内容的细分，并有效降低细分领域的入门门槛。同时也会必然会淘汰大量低级劳动力，特别是在自动化、智能化方向的工程实践，未来一定会淘汰一大批入门级的前端工程师。

如果一定要给建议的话，对于那些目前已经在前端岗位的同学，我建议要找到自己在前端的细分领域，然后持续深入下去。

We are hiring

淘系技术部依托淘系丰富的业务形态和海量的用户，我们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向未来的商业创新和进步。

请投递简历至邮箱：[email protected]

END

了解更多

点击下方图片即可阅读

Weex、RN还是Flutter？资深技术专家与你聊聊阿里跨平台思路