前端早早聊|崇志 - 如何设计大型前端团队基建路线

2020/3/19 11:02:12

编程Tag： 前端框架敏捷开发

本文主要是介绍前端早早聊|崇志 - 如何设计大型前端团队基建路线，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前端早早聊大会，前端成长新起点，帮你提前一星期，站在新的起跑线，目标成为用得上，听得懂，抄得走的前端大会，计划 2020 年办 12 期，由前端早早聊与掘金联合举办。

第一期 2020.1.11 在杭州举办，主题「前端转管理」，450 人报名参加，反响强烈
第二期 2020.2.29 在线上直播，主题「前端搞基建」，760 人报名参加，反响强烈
第三期 2020.3.28 在线上直播，主题「前端搞搭建」，报名请加关注「前端早早聊」公众号跟进历届大会 PPT/录播视频/图文讲稿，回复 "大会" 二字获取。

第三届报名链接：www.huodongxing.com/go/tl3

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

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

自我介绍

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

业务介绍

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

前端工程化发展之路

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

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

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

前端基建跟工程化的关系

首先因为我们集团内各 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 在线上直播，主题「前端搞搭建」，扫码关注「前端早早聊」公众号参与报名：

这篇关于前端早早聊|崇志 - 如何设计大型前端团队基建路线的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！