我在美团三年的前端工程化实践回顾

时间过得真快，从20年9月加入美团，转眼已经三年了。在美团的这几年，我应该有接近一半的时间，在做前端工程化相关的工作。

三年，正好合同已经到期，也到了离开的时候，最近相对不忙，正好回顾一下自己做前端工程化的一些思考与踩过的坑。

对前端工程的理解

前端技术的演进

在谈前端工程这个概念之前，我们先回顾一下2000年以后前端技术的演进，主要分四个阶段：

• 
  
• 页面开发阶段（2000~2009） ：在ECMAScript 2009发布之前，很多前端工作都是以单页面开发为主，需要重点解决兼容性问题，靠工具库提高效率，代表技术如：jQuery、ExtJS等。
  
• 模块化开发阶段（2009~2015） ：以模块化开发为主，要解决性能问题，靠构建工具和UI框架提高效率，特别是基于Node.js的各种前端工具，代表技术如：Angular、React、Less、Gulp等。
  
• 应用开发阶段（2015~2022） ：以应用开发为主，要解决工程化问题，靠自动化工具和跨平台提高效率，代表技术如：Webpack、React Native、Flutter等。
  
• 智能辅助开发阶段（2022以后） ：将前端工程化与 AI 结合，将重复冗余的流程通过智能化实现开发提效，实现智能代码生成、评审、智能编写单测、代码语言转化等。
  

软件工程的三要素

同时，我们也需要了解一下软件工程的概念。1983年IEEE是这么定义的：软件工程是软件开发、运行、维护和修复软件的系统方法。

基于此，软件界一些前辈提出了软件工程的三要素：

• 
  
• 方法：是完成软件开发的各项任务的技术方法，为软件开发提供“如何做”的技术。
  
• 工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境。
  
• 过程：是为了获得高质量的软件所需要完成的一系列任务的框架。
  

前端工程化的定义

前端工程化这个词，是国内前端圈子2018年前后才出现的，大概的意思是将（后端已经比较成熟的）许多软件工程概念、实践、工具引入前端开发，提升开发效率。

关于前端工程化的定义，众说纷纭。我们团队在21年初，经过三个多月的调研和讨论，才形成了一个大家都能认可的定义：在前端开发和运维过程中，以降低成本、提高效率、保障质量为目的，通过一系列规范、工具、流程（分别对应软件工程中的方法、工具和过程）作为手段的实践体系。

前端工程化的演进

美团由于业务广泛，大大小小的前端团队得有30个以上，每个团队的业务场景不同，都会建设或采用一套合适的前端工程方案，但其演进过程，一般都会经历以下阶段：

• 
  
• 工具化：以针对各自业务场景开发脚手架为主，内置常用的前端组件库，提供代码格式检查、埋点及监控等插件，提升项目初始化的效率。
  
• 规范化：面向完成需求的整个研发流程，梳理需求管理、视觉交互设计、评审、开发、联调、测试验收、上线部署和质量监控等相关的规范，进一步建设工具来约束研发过程中的不确定性。
  
• 平台化：将支撑研发的有关工具和系统聚合起来，通过套件和插件的设计模式，实现对不同场景的支撑，支持在线初始化项目，横向打通研发的整体链路。
  
• 体系化：紧跟前沿技术，集成低代码、在线IDE、代码智能生成或推荐等能力，建设需求、设计、研发、运营一体化的云开发平台。
  

中后台项目的工程化实践

工程化演进的动力，源于业务复杂度的增加及团队规模的扩大。我在美团工作过的两个部门，都是属于基础研发平台的，在我加入后，所在前端团队需要开发维护的中后台项目都在变多(第一个部门有60多个，第二个部门也有10多个)，团队规模也进一步扩大(第一个部门30多人，第二个部门10多人)。

在第二个部门的工程化，主要借助我在第一个部门的前端工具建设，进行定制化应用。因此，着重介绍一下我在第一个部门的前端工程化实践。

工具建设

团队的工具建设，开始于2018年，为了建设美团私有云平台，需要收拢美团基础研发平台所有 IaaS、PaaS 产品，预期两年内会有几十个增量项目接入，我们需要提供高效、稳定的前端支持。急需解决的问题有：

• 
  
• 缺乏研发工具。 这一时期，我们的开发手段还比较原始，业务强相关的大量重复工作难以避免，如：前端工程的搭建，接入统一通用的SDK。
  
• 机器资源不足。 当时的前端项目还是直接部署在机器上，团队能申请的机器资源有限，难以承接即将接入的大量项目。
  

针对这两个问题，首先我们建设了自己脚手架工具，并统一了研发流程：

• 
  
• 项目模板：我们提供了两套模板用于初始化项目，一套适用于接入私有云平台(面向美团所有研发，需要统一的顶导、侧导，对视觉交互要求高，上线管控严格)，一套适用于普通的后台管理(只是部门内少数研发使用，重在快速实现功能)。
  
• 研发工具：通过一套自研的中后台组件库把控整体的视觉交互，并提供私有云平台本地开发调试的代理转发工具，解决接口请求的鉴权问题。
  
• 集成服务工具：提供了将本地静态资源发布到云存储和接入公司埋点监控等服务的工具，简化和统一了不同项目接入相同的服务。
  

其次，我们升级了静态资源部署方案：团队的前端大多数项目都是纯静态页面，可以使用云存储代替机器存储，从而解放大多数机器资源。故而我们基于 s3plus 对象存储，研发配套的部署工具，实现了静态 web 项目的无服务架构。

规范制定

到 2020 年的时候，我们需要支持 80 多个基础技术中后台项目的前端工作，当时团队支持项目上存在以下 2 个问题：

• 
  
• 无规范，协作难。 随着团队规模的扩大，各个小组的规范和工具出现分叉，同类项目有多套规范及协作工具，跨项目及跨职能协作同学认知和上手成本高，跨项目协作或人员调动阻力大。
  
• 工具分散，存在内耗。 团队共存多套同类工具，低水平轮子多，维护成本高；工具没有形成生态，不能发挥规模效应，效率提升有限。
  

首先，我们联合多个小组接口人，共同梳理标准规范，并通过标准宣讲，拉齐各职能角色的认知，最终形成了六个大类(分别为需求、设计、研发、发布、架构和运维)、26个小类的文字版规范。

然后，我们联合多个部门的前端物料接口人，基于中后台项目前端界面的常见场景，制定了统一的设计规范，从零建设区块和页面模板库，整合已有的基础组件、业务组件和项目模板，形成了完整的前端物料体系。

接着，我们把发布工具从 Plus 平台迁移至 DevTools 流水线，并且通过 WebStatic 平台进行静态网站托管。这样的好处是，发布规则可以通过流水线定制，加入标准化监测度量等工具，从而实现卡控；流水线运行的容器天然可以作为中转站，将前端资源发布S3，解放了机器；WebStatic 平台接管静态网站托管，可以让我们省去复杂重复的路由配置。

最后，我们采用“普法”和“执法”并重的原则，首先通过课程分享和改造宣讲，普及并对齐标准化的价值，完成团队“普法”过程。“执法”前，我们基于标准沉淀多种一键接入工具降低接入成本；无法自动接入的标准，官方给出最佳实践及预计改造时长，协助业务同学排期；“执法”中，提供了检查工具，用于标准校验并收集项目标准化数据，帮助标准化持续运营。

同时，我们把规范标准区分“强制”、“推荐”两个等级。存量项目只需遵守“强制”等级，不影响项目进度的前提下达成团队标准下限；对于增量项目，提供工具高效遵循全部标准。

搭建平台

2021年团队引入了大量前端外包同学，原本的研发工具及增量项目的服务搭建对于外包同学，都有较高的学习成本，因此这一年我们将提效的重点放在了研发工具的体验优化，以及发布规范、架构规范的配套工具落地。主要解决如下问题：

• 
  
• 架构规范难学习。项目从创建到上线，需要对接代码仓库、Appkey、发布工具、资源托管服务及网关配置等，涉及基础服务产品多，申请及系统切换操作复杂，即使工作经验丰富，也未必熟悉项目所需的全部中间件。
  
• 部分研发工具难上手，体验较差。研发套件中包含工具类型繁多，建设初期，文档完善程度参差不齐，高频使用的物料工具对于新人上手也不够友好。
  

我们决定通过建设研发工作台落地架构规范，通过自动化的研发流程串联降低新人学习成本，快速搭建增量项目；同时，为解决研发套件使用体验问题，我们同步建设了 VSCode IDE插件，集成高频使用的插件、物料使用等工具，降低学习和切换成本，增强用户的使用体验。

同时，为满足不同业务场景的定制需求，我们将各场景研发流程抽象成 「场景模板」， 它是最佳实践的载体，前文中的自动化创建流程就是基于场景模板来串联。

场景模板由初始化模板（生成项目基础结构），研发工具插件（CLI 层面的插件 preset），基础服务配置方案组成，每部分可以灵活配置，一定程度上满足不同业务场景的定制需求，团队工程负责人可以按需定制自己的场景模板。

平台化以后，我们的前端工程方案就可以满足公司更多部门接入使用，发挥更大的价值。比如，我转岗的部门在推进工程化的时间，基于这套方案，只需结合视觉项目的特点，替换前端物料、生成项目的脚手架即可。

形成体系

2022年外包团队规模和产品规模即将进一步扩大，然而当前工具对于效率的提升也逐渐出现瓶颈，我们期望对当前的主要业务场景，即对中后台业务，进行深度提效的探索。另一方面，现有大部分规范已有配套工具保障，但前置的需求以及后置的运维环节依然没有形成闭环，我们期望平台能有更沉浸式的体验，建设中后台场景的体系化解决方案。需要解决以下问题：

• 
  
• 提效瓶颈，研发提效工具待加强： 分析业务现状和参考业界，传统编码（ProCode）的辅助工具完整性和易用性需持续加强，业界的低代码（LowCode）实践也很适用于我们的中后台场景，我们也将在这一领域探索建设。
  
• 需求、运维规范未闭环： 当前的平台能够串联从创建项目到部署的研发流程，但是前置的需求、设计管理和后置的运维规范还不完善，对于相关工具（如项目管理和监控工具）的应用也没有形成标准。
  

我们希望将研发工作台打造为云开发平台，通过集成在线 IDE 开发工具和低代码自动化研发工具，对于中后台场景深度提效；同时也要与项目管理、设计平台、监控等平台加深协作与融合，串联前置的需求设计环节与后置的运维环节，形成中后台场景的体系化开发平台。

sdk项目的工程化实践

2022年初，为了从北京换到深圳定居，我换了部门，在新的部门，需要开发维护的npm包比之前多了很多。如果没有统一的工程标准，不仅开发维护的效率很低，同时SDK的易用性也会比较差。

过去一年，我参与了多个SDK项目的开发维护工作，同时前两年也参与了面向公司的中后台前端项目的工程建设，于是我将这些实践和采坑经验进行总结，形成了一套前端sdk项目的工程标准。

业务项目和SDK项目的区别

通过表格对比可以看到，业务项目和SDK的项目还是有较大区别的，除了有一些公共标准可以复用外，SDK项目需要增加打包构建、发npm包、多包管理、文档管理和门户建设等相关的工程标准。

工程方案

我们基于业务项目制定的规范，对于有差异的部分，比如依赖包管理方案、目录结构、文件命名、本地开发等，制定了新的规范；而对于没有包含的部分，比如文档管理、官网建设、发布npm包及其权限管理等，补充了新的规范。

我们基于前面建设的云开发平台，提供了一个面向 SDK 开发的场景模板来创建项目：创建成功后，会自动注册前端appkey，创建仓库并使用sdk的项目模板初始化项目，把sdk官网的静态资源接入webstatic，并接入发布流水线，提供默认域名供用户访问。

相比之前的方案，这个方案不仅开发调试及发布验证更加方便，还能提供默认的域名访问该sdk网站，让用户可以快速查看相关的接入文档和教程，体验sdk提供的功能。

相关说明

整个项目使用vite工具进行构建，使用rollup 进行打包，打包成功后，即可通过本地或流水线发布到公司的私有npm。

我们没有使用lerna进行多包管理，而是使用了pnpm的方案，所以要求必须本地安装pnpm，然后通过pnpm安装package.json文件中引入的npm包。

只需配置根目录下的pnpm-workspace.yaml文件即可，示例如下：

packages:
- 'packages/**'
- site

在packages目录下，一个子目录对应为一个子npm包。site 目录为sdk 对应的官网代码，本地开发时，可以在site 中的某个页面，引入packages中的某个包进行源码调试。

在根目录执行 npm start 就可以打开sdk 官网了，然后跳转到demo 演示的页面，修改site目录下对应页面或者packages下对应的npm包，即可开始进行SDK的开发调试了。

所有的文档管理相关代码，都在site 目录下的src目录，如果需要更新文档，直接在markdown 目录编辑对应的文档即可。

如果发布了新的sdk，需要验证sdk的可用性，需要先将site目录下package.json文件对应的npm包修改为最新的版本，提交后远程仓库后，再选择对应流水线发布到自己想验证的环境。

总结

在美团工作的三年，在技术和视野上，对我的帮助都很大，接触的领导和身边的小伙伴都很优秀，有些工作是我对最终结果负责，有些我只是重在参与。

我们会把事情分为业务开发和框架（工具）开发：

• 
  
• 业务开发主要是实现产品需求，要对业务有深入了解，掌握团队所用到的技术栈和工具。
  
• 框架（工具）开发主要是为提升业务开发效率而开发的框架或工具，框架是把系统可复用层抽象出来，如网络层，存储层等，工具是研发过程中效率工具，如自动化测试工具，持续交付工具等。
  

通常上系统是有多个模块组成，那么会有一个从复杂到简单的拆解过程，既然系统有分层架构，那我们会按照每个人技术水平来安排不同复杂度的工作。我们要不断提升两个标准，一是通过对人才的培养提高上限，二是通过工程工具建设提升团队下限。

工程化永远是围绕着质量、体验和效率三个维度进行建设，来保证高效、高质量地完成业务需求，减少跨项目、跨团队的协作成本。但前端工程化不是万金油，它是在特定时期面对特定场景的解决方案。

平台体系的建设往往会被业务结构和技术架构所约束，要尽量结合团队的业务场景和技术现状来制定合理的解决方案，避免仅凭个人的技术思考来主观驱动，所以还是要结合自身组织特点，先清楚地认识自己所处的阶段，再去实践并验证。

老王（王慧文）在演讲曾提到过：“不要为自己设限”，所以前端工程师在前端工程化中，应该积极承担业务工程化建设或工程工具建设工作。《论语》中说道：“工欲善其事，必先利其器”，所以面对复杂工程，我们要学会用工具来提升效率，使复杂问题简单化。

2023年我的主要精力都在做前端智能化，在工程化上的投入比较少，但是我相信借助AI，前端工程化一定会迎来重大的变革。