第二届搞基建|崇志 - 如何设计大型前端团队基建路线

前端早早聊大会，前端成长的新起点，与掘金联合举办。加微信 codingdreamer 进大会专属内推群，赢在新的起跑线。前端

第十四届|前端成长晋升专场，8-29 即将直播，9 位讲师(蚂蚁金服/税友等)，点我上车👉 (报名地址)：json

正文以下

本文是第五场讲师 - 崇志的讲稿文字版，来看看他是如何讲的，视频及 PPT 将来在公众号放出。后端

你们下午好，我今天要分享的主题叫【大型前端团队的基建设计整合之路】，主要会跟你们分享下咱们团队这么多年积累下来的前端基础设施相关方面的一些成果和心得。前端工程化

自我介绍

简单自我介绍下，我叫崇志，我是阿里妈妈的前端技术专家，入职大概 8 年多，目前主要专一在团队的前端工程化上，右边是个人钉钉二维码，有想进一步交流的同窗，能够加我钉钉。缓存

业务介绍

主要的业务是一些对接商家的后台管理型站点页面，好比像钻展，直通车，达摩盘之类的，这些站点都是 SPA 单页应用构架，交互也比较复杂，好比像一些很复杂的计划建立流程，报表展现之类的。还有就是这些应用基本都是维护不少年了，迭代也很频繁，而后如何保持这种项目长期的可维护性，代码的健壮性都是咱们团队长期在关注和优化的点。另外还有一类是属于知识站点类，基本上都是一些静态的文档内容。还有一类是营销活动类型的页面，好比像双十一活动，年货节这类的，都是上线时间很短的一些页面前端框架

前端工程化发展之路

在早期的话，基本上咱们前端都是以开发页面 demo 的形式而后提交给后端去套 Java 的 VM 模板之类的，先后端代码耦合严重，另外就是前端基本没有本身的本地开发环境，都是让后端工程师帮忙安装后端的开发环境，好比 JBoss，Tomcat 之类的，而后才能进行调试，很是麻烦。服务器

到了如今整个前端工程化以后，基本上就能够作到一个是先后端分离，这个主要是 SPA 单页应用构架以后带来的结果，后端基本只须要提供接口给到前端就能够。另一个就是咱们会作一些脚手架工具沉淀，包含一些最佳实践配置，而后新开发项目的话基本就能够作到开箱即用。还有就是如今有很完善的本地开发环境，主要就是用 Node.js 开发的命令行工具，能够提供本地开发时对接模拟接口，而后在联调时能够对接后端真实接口的能力。而后咱们也作了单独的接口管理平台，这样开发项目时只须要前期让后端开发者在平台上录入接口信息，就能够先后端并行开发，互不干扰。还有就是咱们也作了专门的数据埋点统计平台，方便运营或产品来直接的看效果数据。最后就是咱们如今的项目都是在云端构建跟发布的，带来的好处一个是项目仓库里再也不有 build 之类构建后的代码，另外就是能够保证项目构建环境的一致性。微信

在这整个前端工程化的过程中沉淀了不少前端的基础设施，后面我会逐个简单介绍下。markdown

前端基建跟工程化的关系

首先由于咱们集团内各 BU 的前端团队很是多，这么多年下来其实已经累积了很多颇有亮点的单点基建，能够说轮子很是多，因此咱们这边工程化的思路就是先梳理好咱们本身团队的前端开发流程，在各个流程上都先去调研集团或社区内有没有什么能够为我所用的工具，若是有就看看可否这些工具之上进行二次开发，以更好的符合咱们团队的开发需求，若是没有就能够尝试自行研发，而后将这些全部基建工具整合串联起来，覆盖到整个前端开发链路，最后就能够达到提升开发效率的目标。架构

前端开发的全链路过程

基本上包含如下这些流程，包括项目初始化、本地开发、接口联调，数据埋点、构建发布，还有就是性能监控。咱们的思路是经过开发一个命令行工具 rmx-cli ，来将整个前端开发链路串联起来，也是经过这种方式将散在各处的前端基建整合起来，来达成 1 + 1 > 2 的效果。

接下来我会围绕着 rmx-cli 命令行工具来说讲咱们前端开发全链路上的各个基础设施的状况。

前端开发链路里包含的基建

在项目初始化，本地开发，接口联调这些流程里咱们有如下这些基建，包括最基本的项目代码管理，咱们是用 GitLab 来管理的。而后前端框架体系，咱们有自研的 Magix 体系框架，部分项目是用了如今社区很成熟的 React 体系。而后基于 Magix 框架，咱们有自研的组件库 Magix-gallery 。还有咱们也在本地开发时提供了可视化搭建的插件，Magix-desiger。而后咱们也有一个自研的叫 MAT 的本地开发联调服务插件，主要提供本地开发服务，接口模拟，接口代理等功能。接口管理部分则是有一个叫 RAP 的接口服务平台，底层是用到了 Mock.js 的能力。字体图标方面则是用到了 Iconfont ，这个你们应该都比较熟悉，是咱们阿里妈妈开发的一个字体图标管理平台。图表体系则是用的咱们自研的图表管理平台： Chartpark ，相似组件库同样，提供经常使用的各类类型业务图表。

在数据埋点方面咱们有自研的 Dataplus 平台，提供单页应用页面的自动埋点，以及埋点后的效果数据查看。性能监控方面，咱们是经过命令行工具接入了集团的 Clue 监控平台，会在项目初始化时自动接入。另外就是咱们也有一个自研的相似 TMS 的内容管理系统 ALP ，主要是用来快捷发布一些活动页面之类的功能。最后在构建发布方面咱们有 Magix 体系的 Magix-combine 来负责代码的构建，同时咱们也经过命令行工具接入了集团的 DEF 平台来实现前端资源的云端构建发布能力。

命令行工具 rmx-cli

早期咱们团队成员在开发项目的时候，每一个人都有本身的方式去处理本地开发服务的问题，好比有的人用 Nginx ，有的人用 Java 的服务器，环境很不统一，在须要开发对方项目的时候，环境的搭建是一个很繁琐的事情，后来 Node.js 出来了，咱们就想着是否是能够搞一套基于 Node.js 的命令行工具来将整个开发流程给统一块儿来，因此就有了 rmx-cli 命令行工具。这个命令行工具也迭代了不少个版本，从最初的只支持 Maginx 体系，到如今利用套件体系能够支持其余不一样的框架体系，更具备通用性。

而后来看下如今 rmx-cli 命令行工具的基本架构， rmx-cli 主要是三层结构，一个是底层是 Cli 命令行入口，主要提供一些系统的命令，好比登陆，登出，安装卸载之类，中间层是 Rmx-core 核心包，主要提供系统命令和默认套件命令的具体实现逻辑。另外就是最外层的套件和插件体系，负责不一样框架体系的具体的命令逻辑实现。一些比较基本通用的套件命令咱们会在命令行工具里直接内置，好比像 init 初始化， build 构建， publish 发布等等这些命令。而后不一样框架体系有特殊逻辑的命令能够经过重写或增长套件命令的形式进行自定义扩展。

插件命令属于跨框架的全局的通用命令，好比咱们就有一个 clear 插件专门用来清除 Chrome 的 HSTS 和 DNS 缓存。而后插件体系也是支持扩展的，任何人均可以按照咱们的插件规范开发一个插件包，而后申请接入咱们的插件体系。

另外就是咱们也作了配套的 Webui 工做台，基本上就是对 Cli 命令行的可视化实现，背后的核心逻辑是同一套代码，而后同时供 Cli 命令行和 Webui 调用。咱们能够在 Webui 工做台里进行开发命令的可视化操做，项目的管理，还有套件和插件的安装和删除等等功能。

前端开发框架 Magix

Magix 是咱们阿里妈妈自研的区块化管理框架，主要应用场景是 SPA 单页应用（同时也支持传统的多页应用）。 Magix 在咱们阿里妈妈的历史比较悠久，甚至比 React 当年出来的还要早一些，是咱们常年开发那些后台管理型站点所慢慢沉淀出来的一个框架，通过不少个版本迭代，如今基本上已经很成熟稳定。Magix 主要是以 view 来作区块化开发管理的，包括组件库的组件也是基于 view 写的。而后也提供双向绑定的能力，还有就是咱们配套开发了 Magix-combine 离线处理插件来提高性能，好比 HTML, CSS, JS 的合并，样式的局部隔离等等。另外就是借助 rmx-cli 命令行工具，咱们也实现了在本地开发时，实时热更新的能力。

前端脚手架 rmx init

事实上咱们在这么多年的业务开发过程中，确定会有不少不一样类型的包含最佳实践的前端脚手架沉淀下来，在开发新项目的时候就能够直接初始化使用。咱们这边主要是经过命令行工具的 rmx init 命令来进行脚手架初始化的，能够看下大体的运行效果。这个命令只要输入项目名称就能够一键初始化项目环境，快速投入开发，包括帮助你在本地和 GitLab 上都建立好项目，对接各个平台等等。

而后看下咱们 rmx init 的具体流程，首先咱们会先选择一个套件，好比 Magix 或者 React ，而后再指定脚手架，脚手架支持不一样类型，好比后台管理型跟营销页面型的站点，而后再输入一个项目名称，肯定好后 Cli 命令行就能够自动在 GitLab 平台建立好相应的项目。还有就是对接各个开发平台，好比接口管理平台 RAP , Iconfont ， Chartpark 等等，也会在相应的平台上建立好项目，而且将项目 id 配置到项目的 package.json 中，供后续 Cli 命令行工具在本地开发中使用。基本上咱们经过套件体系和多脚手架选择就能够覆盖到大部分不一样类型的项目初始化需求，能够作到开箱即用，很好的提高了开发效率。

本地开发服务命令 rmx dev

这个也是咱们整个前端开发链路里很是核心的环节。 rmx dev 时会在本地起一个 KOA 服务器，根据项目中配置好的 RAP 的项目 id ，就能够作到本地开发时的接口模拟数据来自 RAP 平台，同时 rmx dev -d 加后端提供的接口 IP 地址的话，就能够直接跟后端联调真实接口。而后利用 RAP 平台数据也能够作到本地接口校验的能力，提升接口的准确性。另外就是也支持直接联调线上 HTTPS 类型的接口，由于如今线上环境大部分都是强制要求 HTTPS 的，若是要在本地开发联调线上接口的话，就须要在本地也要搭建 HTTPS 服务，这个有作过的人都知道很麻烦，须要安装签名证书什么的，因此咱们作了一个很取巧的方式，就是本地仍是起的 HTTP 服务，而后接口经过咱们的 MAT 插件转发到线上接口时加上 HTTPS 协议，就能够绕过这个问题了。

还有就是本地开发时咱们加了不少提升效率的辅助功能，好比 Magix-hmr 支持对 Magix 项目的实时热更新。而后咱们会在本地开发时页面注入帮助文档，在开发时方便查看，同时咱们也注入了 Magix-desiger 可视化搭建系统，能够快速建立指定模板的页面。还有就是咱们的本地开发服务会直接接入 Magix-combine 进行实时离线编译。

开发帮助浮层工具 rmx dev

咱们如今开发的项目通常都会有不少配置，好比像各个关联平台的项目 id ，还有开发环境的接口 IP 地址之类的，而后这些配置咱们就经过浮层的形式注入到本地开发页面中，很方便的以可视化的形式进行配置的修改与保存。另外就是提供一些帮助文档的地址，好比 rmx-cli 使用文档、组件库文档地址等等，方便在本地开发时查看。

微前端

时下很热门的一个概念：微前端，咱们这边也有在 Magix 体系下作了相关的尝试。

来看下业务场景：一开始咱们可能只有一个达摩盘项目，而后过了一段时间产品说我要再开发一个达摩盘小二版和服务商版，他们是不一样的域名站点，可是里面的某些模块页面好比人群列表是同样的。而后咱们想到的思路就是这个通用的人群列表模块是否是能够以 view 的形式加载到其余项目中，可是这三个项目实际上是不一样的仓库，直接加载是不行的，因此咱们须要作些处理。

固然若是用 iframe 加载的形式也是能够解决刚才提到的那个业务场景，但 iframe 方案的弊端也很明显：一个是由于 iframe 是彻底隔离的，HTML, JS, CSS 都是完整加载的，加载速度会慢不少，割裂感很明显。另外就是 iframe 的样式宽高无法像 div 那样自动撑开，要处理 iframe 的自适应的宽高是一个很麻烦的事情。

因此咱们这边是用到 Magix 里面一个 vframe 加载的方案， Magix vframe 是用来管理 view 的，若是咱们要跨项目加载其余项目的 view 的话，咱们只须要配置跨项目的前端资源地址，以及跨项目的接口 host 配置就能够实现。而后咱们的 Magix-combine 离线编译插件提供了 scope 样式隔离的能力，避免被加载的模块影响宿主样式。通用样式会进行本地化，就是你的 view 被加载进另外一个项目时，通用样式会直接用对方项目的。而后由于都是 Magix 项目，因此咱们组件库是共享了同一个，避免屡次加载的性能问题。而后咱们也加了一个 xSite 插件作到资源按需加载，就是有加载那个 view 的页面时，才加载相关资源。

这样基本就能够作到不一样的项目模块能够互相加载的能力，大大提升模块的跨项目的复用性。

而后基于跨项目加载 view 的这个能力，咱们也开发了一个配套的 Chrome 插件，用来辅助本地开发时，配置跨项目加载的子 view 的前端资源地址和接口 host 配置。也就是咱们能够在本地同时起两个项目的服务，而后修改 Chrome 插件的配置，就能够同时调试开发两个项目的代码，而不须要改动到项目里的相关配置代码。
另外就是这个 Chrome 插件也能够在访问线上站点的时候，修改跨项目加载的子 view 的配置，直接进行子 view 的本地调试开发。

可视化搭建 Magix-desiger

最先没有任何工具的时候，只能是经过手动建立页面，再 copy 一些现有的页面代码，而后再进行开发工做。后来咱们有了 rmx-cli 命令行工具后，经过 rmx add 这个命令来直接生成预设好模板的 view 页面，好比表格、表单这些通用类型的页面，也能够选择根据 RAP 平台的接口生成与接口相关联的页面，可是基本上仍是比较固定化的模板方式，不是很灵活。

为了解决相似这种快捷搭建经常使用页面的效率问题，咱们就开发了 Magix-desiger 可视化搭建插件，接入咱们的 rmx-cli 命令行体系。主要是经过编写 Schema 描述模板，再结合 RAP 平台的接口数据，在本地开发时注入一个可视化的操做界面，来进行实时快捷的页面搭建。后来更进一步，咱们也加入了 AI 识别设计图直接生成页面的能力，就是直接上传一个设计图，系统能够自动识别出图片里的下拉框，表格，表单输入框等元素，自动的生成页面，而后开发人员再基于这个生成的页面继续开发就能够了。

到目前 Magix-desiger 可视化搭建系统，甚至能够提供给后端开发人员进行一些经常使用的表单或表格页面搭建，减轻了很多前端的工做量。

咱们来看下一大体的运行效果：

就是在本地开发的时候，经过 rmx-cli 命令行工具在页面上注入 Magix-desiger 相关的 JS 文件，Magix-desiger 插件会在本地起一个 WebSocket 服务进行一些文件的读取、写入之类的操做。而后依赖这个插件就能够直接在页面上进行操做，能够新建一个页面，也能够选取当前的页面进行编辑。

接口管理 RAP

咱们这边开发的一个用来管理接口模拟数据的平台：RAP

由于如今咱们主要的业务都是先后端分离的开发模式，跟后端最重要的一个交互方式就是经过接口，因此咱们开发了 RAP 这个平台专门用来维护接口信息。这个平台主要提供了接口信息录入、文档说明、还有接口模拟数据的功能。

来看一下这些年咱们团队关于接口管理的发展过程：

Mock.js 可能你们都有据说过，是咱们这边的一个同事开发的专门用来生成模拟数据的 JS 库，而后早期的话，咱们就是把 Mock.js 库直接引入项目，同时在项目中保存 mock 数据的规则文件，来解决最初只能在具体的业务页面手动模拟接口的痛点。这样作带来的问题一个是上线的时候须要将 Mock.js 移除，另外就是 mock 模拟规则文件会在项目中冗余。

因此为了解决这些问题，咱们开发了 RAP 接口管理平台，接口 mock 规则信息就统一维护在平台上，不须要在本地储存 mock 数据了，可是在本地开发环境中须要引入一个 RAP.js 文件来将接口转发到 RAP 平台来获取模拟数据，另外还须要在项目代码里判断是不是本地开发环境，至关因而在生产环境的代码中仍是冗余了一些本地开发时的辅助代码。

而后到如今咱们经过 rmx-cli 命令行工具，在本地开发阶段就能够将接口经过命令行工具转发到 RAP 平台获取模拟数据，再也不须要 RAP.js 文件在前端代码层面进行接口拦截与转发。还有就是咱们也提供了命令来将 RAP 平台上配置好的接口信息直接同步到项目中，不须要在项目中手动的维护接口列表信息。另外就是咱们如今有 RAP 平台的接口信息，同时也有本地开发时的接口请求信息，这样咱们就能够作到在本地开发时校验接口的能力，就是能够有效的校验后端返回的真实接口信息与 RAP 平台上的接口信息是否匹配。

而后目前咱们的这种解决方案，就是能够作到在生产环境中没有冗余的侵入式的代码，同时咱们前端也再也不关心接口的维护，基本上都是由后端同窗在 RAP 平台上录入他们的接口信息就能够了， RAP 平台同时也承担了接口文档说明的功能。

组件体系 Magix-gallery

咱们基于 Magix 框架开发的组件库， Magix-gallery 。组件体系在一个相对大一点的团队里基本上都是要自行开发的，也只有自研的组件库才可以快速响应视觉交互对组件的高定制需求，也利于咱们统一跨产品线通用组件的前端交互行为。咱们组件库积累到目前已经有 60 多个通用组件和业务组件，基本涵盖了大部分的交互类型，同时也在组件层面提供了双向绑定的能力，提升平常业务开发体验。事实上咱们的组件库成熟稳定以后，平时开发平常业务，基本上就是拼装各类组件，而后再加一些逻辑代码就完成了，这样就能够有很高的【平常业务】的开发效率。

而后咱们也将 rmx-cli 命令行工具与组件库相结合，提供了一键同步组件代码到项目中的能力，也支持指定某个版本的组件同步，还有就是在组件有新版本时，会在命令行里给到升级提示。

而后由于咱们产品线有不少，并且主题色都不同，因此咱们组件平台提供了一个快捷编辑主题颜色的功能，只要选取一个主题色，其余全部的辅助颜色就会自动生成，也能够再细调各个辅助颜色，最后提供下载到本地的功能，就能够直接应用到项目中了。

图标管理 Iconfont

咱们团队开发的图标管理平台 Iconfont ，这个应该你们都比较熟悉了。

目前同时支持单色的 Webfont 形式，和多色的 SVG 形式图标，而后也能够提供设计师上传 SVG 图标，并在线调整的能力。

而后看下咱们团队图标方案的这些年发展过程：

早期的话页面上若是要有图标，基本上就是从 PSD 里切出来，而后为了减小请求，会将全部的图标拼在一块儿，经过位置来决定用哪一个图标，这种方案基本上缺少灵活性，大小、颜色啊都是固定的。

后来咱们基于 Webfont 的形式开发了 Iconfont 图标管理平台， Webfont 的优点很明显，就是大小跟颜色能够随便定义， HTML 里面引用也很方便。可是 Webfont 形式最大的弊端就是只能是单一颜色，因此后来咱们也加入了 SVG 模式，能够支持多色图标。

而后如今经过 rmx-cli 命令行工具，咱们在初始化项目的时候，就能够自动在 Iconfont 平台建立好关联的项目，而后在开发时能够在 Iconfont 平台上添加好图标以后，经过命令一键同步字体配置到项目当中。同时 cli 命令行工具也提供了用来检测项目中是否有冗余图标字体的命令，这个主要是为了解决项目长期维护致使的 Iconfont 项目无效字体愈来愈多的问题。

图表体系 Chartpark

看一下咱们团队的图表体系 Chartpark ，先说下咱们为何要本身研发图表库：

一个是由于咱们产品对图表的需求不少都是很定制化的，只有咱们本身开发的图表体系才能快速响应他们的需求。
另外就是咱们后台管理型页面的不少图表都是有很高的交互效果的，自研的图表库才可以更好的开发出相应的互动效果。

来看下咱们的图表体系构架，主要分了三层：底层 Canvax 库是封装了 Canvas 的 context2d 和 Webgl 的渲染器功能。而后中间层 Chartx 库是基于 Canvax 作了对常见业务图表的封装，好比柱状图，饼图之类的。最后的就是最上层的 Chartpark 图表管理平台，主要是对项目的图表配置进行集中管理。

而后这个就是咱们的 Chartpark 图表管理平台，通过多年来的沉淀积累，如今官方图表库已经有 100 多个，基本上能够覆盖业务中经常使用的图表类型。
复制代码

咱们当初作这个平台的目标是但愿有一个能够直观的配置图表的地方，来快速的知足交互视觉对图表的定制需求。因此咱们作了这个平台来将项目里全部图表的配置集中在一块儿进行开发调试，项目中只须要配置图表的 id 就能够了。
因此咱们这个平台提供了在线编辑预览图表的能力，在线配置好图表以后，就能够经过 rmx-cli 命令行工具一键同步图表库配置到项目当中，无须手动操做。另外也能够支持直接下载配置好的图表库到本地，而后经过 import 的形式引入到项目中使用。

埋点平台数据小站 Dataplus

当时开发这个平台的背景：一个是由于咱们的产品、运营、交互对业务产品有很强的打点需求，来印证他们上线的产品的效果。另外就是咱们集团已经有一个很成熟的传统页面埋点平台 SPM ，可是咱们这边主要是单页应用， SPM 不支持单页应用的 UV、PV 的统计。因此后来咱们就基于 SPM 开发了本身的 Dataplus 数据小站平台，主要是解决了一些 SPM 没法知足咱们项目需求的问题，好比自动埋点的功能，还有刚才提到的单页应用的 PV、UV 的统计，另外就是平台产出了有价值的数据报表，主要基于业务的数据，作了用户数据分层，能够帮助咱们的产品经理更好的了解不一样层级的用户在使用各个业务产品的状况。

看下数据小站 Dataplus 的基本构架：

底层埋点是由咱们集团的 SPM 打点系统提供支持，而后数据小站会将 SPM 那边储存的埋点数据拉取到平台上进行个性化处理，而后就能够作业务站点的全站概览，页面分析，单点分析等等功能。还有就是咱们也开发了一个配套 Chrome 插件，在访问业务站点的时候，能够直接查看页面上的 PV、UV，或者某个功能点的埋点数据，还有就是能够在页面上选取某个具体的功能埋点直接添加到数据小站平台里。

而后就是接入 rmx-cli 命令行工具方面，主要就是经过命令行工具，在项目初始化时能够直接建立好数据小站相关的埋点信息，而且配置到项目当中。另外咱们在项目的构建发布命令里接入了自动埋点和同步配置的功能。这样的话基本上咱们开发一个项目，零配置零操做就能够达到全站自动化的埋点。

内容管理系统 ALP

咱们团队也开发了一个通用的内容管理系统 ALP ，它是一个相似 TMS 的页面发布系统。

ALP 诞生的背景主要是为了应对咱们部门愈来愈复杂多变的业务场景，提供一个快速上线产品的能力。好比咱们前端能够基于 ALP 快速的开发并发布一个平常活动页面，还有就是提供给运营像编写 Word 文档同样简单的制做一个推广页面，能够直接发布到生产环境，来完成一次活动宣传。

对咱们后台管理型业务来讲，经常使用的一个功能是 Jsonp 接口管理模块，好比像项目中的活动页浮层，或者一些纯静态展现的文案和图片，而后这些内容又常常改动的页面，咱们就能够用 Jsonp 接口的形式配置到 ALP 平台上，以可视化的形式提供给运营随时去更改内容，这样就能够省去咱们前端不少无谓的重复性工做。

Serverless 体系 Fether

咱们团队如今也在尝试开发的 Serverless 体系：Fether

像咱们团队中有不少自研的服务平台，像数据小站平台，图表 Chartpark 平台， RAP 接口平台等等，这些都须要本身去搭建、运维服务器资源，对前端开发来讲不是很擅长，也是很费心费力的事情。因此咱们团队的同事就基于集团的 Aliyun 计算开发了本身的 Serverless 平台。如今基本上咱们团队内部自研的平台都已经慢慢往 Fether 上迁移了，那用了 Serverless 给前端带来最明显的好处是免运维，不须要关心服务器负载什么的，只须要关注在本身的业务逻辑上就行了。而后咱们也基于平台的能力提供了统一的监控和数据统计功能。

构建发布

咱们这边主要的项目都是 Magix 框架的，因此构建都是经过 Magix-Combine 这个包来执行的，Magix-Combine 是一个为了提升性能的离线处理包，好比模板提早变成 function ，减小线上的临时编译，还有就是样式的 Scope 隔离，以及提供 Typescript, ES6 的支持，还有一些基础的代码错误检测等等。

而后就是发布阶段，咱们在 Cli 命令行工具里集成了集团的云构建平台 DEF ，云构建的好处一个是项目仓库里再也不须要构建后的 build 目录，另外就是能够保证不一样开发人员构建环境的一致性，还有就是平台化之后，全部分支管理、发布记录均可以在平台上进行回溯和查看。咱们经过 Cli 命令行工具也集成了一键发布平常和线上环境的命令，命令内部包含了主干代码的 merge 合并、代码 commit 提交、 SPM 埋点、调用 DEF 云端构建的这些逻辑，基本上免去了全部手动操做的重复性工做。

总结

咱们团队是没有单独的架构组的，因此咱们基本上都是在常年累月的业务当中，去发现问题，定位问题，最后解决这个问题，而后在这个过程中天然而然的沉淀出前端各个面向的基础设施，团队成员也会在这个过程中找到适合本身的前端领域，而且深耕下去。而后随着团队里的各个领域的基建慢慢成熟，就会必然走上前端工程化之路，实际上工程化就是将散落在各个点上的优秀的基建串联起来，最后造成一个适合本身团队的完整的体系化的东西。最后完善的前端工程化一定是会反哺到咱们的业务当中，极大的提升咱们的开发效率和体验。

前端发展到如今这个阶段，虽然比之前那个时代成熟完善许多，可是横向对比其余语言，好比后端 Java 体系，仍是有不少不完美的地方，因此如今远远不是终点，从长远来看仍是有不少前端领域值得去开拓和探索的。

而后就是咱们的招聘广告时间，对，咱们要招人。咱们是阿里妈妈的前端二组，主要业务是对接商家的后台管理型站点。咱们没有独立的架构组，但基本上每一个人都会负责某个领域的基础设施开发，目前整个技术栈铺开的面也比较多，后续发展的空间也比较大。还有就是咱们团队很稳定，不少年没有太大的变更，适合长期发展，氛围也比较轻松。另外咱们是属于阿里系的，福利跟集团靠齐，算是比较好的。最后就是咱们阿里妈妈虽然对外不是很知名，可是是阿里最赚钱的部门，因此你懂的，有兴趣的同窗能够扫描个人钉钉二维码联系我。

第三期 2020.3.28 在线上直播，主题「前端搞搭建」，扫码关注「前端早早聊」公众号参与报名：