前言

我认为前端基础建设的核心就两点：1.提升开发效率，2.提高产品质量。

在做基建过程中我们需要注意几点：

1. 解决问题：做得再花解决不了实际问题也白搭。
2. 价值：决定去做具体事项之前，首先要考虑它的价值，即能否提升业务开发效率，提高产品质量。
3. 数据：当我们需要说服上级管理者或证明价值时，拿出数据才是最有说服力的证明，例如组件使用数据、埋点数据、性能提升数据等等。

基建内容

前端基础建设内容主要包含 4 个部分：

• 工具或方案：在解决实际问题时，我们产出的更多是工具或方案，例如脚手架、组件库、代码检测工具、埋点或监控 sdk 等。
• 规范：为了让整个研发流程顺畅可控，我们需要制定前端相关的规范，贯穿需求分析、视觉交互设计、评审、开发、联调、测试验收、上线部署、运维监控、用户反馈等各个环节，并考虑建设工具来约束研发过程中的不规范行为。
• 体系：将工具和规范整合，体系化、平台化，统一整个研发链路，提供一站式服务。
• 未来：关注新技术，例如 AI 生成、云开发等等，思考如何将新技术转化为生产力。

接下我们介绍一下我们基建做的一些具体工作。

脚手架

脚手架可以很方便地初始化一个前端工程，它包含了基础工程结构、公共依赖包及版本固定、公共组件库和工具集集成、登录功能、规范化配置（eslint、prettier、代码检测 sonar 配置等）、脚本命令(dev、build、lint-check/fix 等)、CI/CD 配置等。

脚手架的主要实现原理是：使用 commander + inquirer 封装终端问询式命令系统，根据用户输入的命令配合 node.js 脚本拉取工程模版并做一些定制化处理。

项目结构规范

我们以 vue 技术栈为例做介绍，第一层项目结构规范和 vue-cli 生成的差不多。

├─api （接口）
├─components （公共组件）
├─layouts （公共布局）
├─router （路由）
├─store （vuex 全局数据）
├─utils （工具函数）
├─mixins （混入）
└─pages （页面）

其中 api、router、store、utils、mixins 都有模块的概念，会根据模块拆分文件。pages 下是各个页面目录，它的目录结构和上述结构相似，同时参考了约定式路由实践，pages 及 layout 的目录结构和路由路径保持一致，便于清晰地知道项目有哪些路由，以及根据路由快速查找对应页面。

同时我们在专项大平台中还实践了另一种项目结构规范，将多个工程整合到了一个代码仓库中。它没有采用 monorepo 的管理方式，主要是在各个目录增加了一层 project 区分，其余项目结构规范和前面是一致的。它的优势在于专项平台的通用能力可以更好的复用，基建相关能力升级的时候不用一个个改每个工程等等，劣势在于多人多工程并行开发、发布存在一定的沟通和管理成本。

前端规范

主要说明一下技术栈规范、代码规范和 git/svn 规范。

技术栈规范：node.js、vue/vue-router/vuex/tdesign/vue-cli、react/react-router/antd/umi、npm/yarn/pnpm 这些版本都是统一的。

代码规范：包含了 js 规范、css 规范、html 规范等，注意借助代码检测工具来约束。

git/svn 规范：分支管理规范、commit 规范。

commit 规范我们只强调了 commit 类型，常用的有 feat、fix、docs 等。

更详细的 commit 类型可参考：

• feat: 新功能、新特性
• fix: 修改 bug
• perf: 更改代码，以提高性能
• refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
• docs: 文档修改
• style: 代码格式修改, 注意不是 css 修改（例如分号修改）
• test: 测试用例新增、修改
• build: 影响项目构建或依赖项修改
• revert: 恢复上一次提交
• ci: 持续集成相关文件修改
• chore: 其他修改（不在上述类型中的修改）
• release: 发布新版本
• workflow: 工作流相关文件修改

UI 规范

设计组针对组件、模块、页面等制定了一系列的设计规范，其核心目的是为了提高 UI 和交互的体验及一致性，前端开发页面时需要遵从设计规范。

代码检测工具

eslint + prettier + stylelint + commitlint + husky 这些规范相关的代码检测工具基本是很多工程的标配了，我们定制并使用了其中一部分，并在脚手架中统一集成。

ESLint：用于检测 JavaScript 代码中的潜在问题、错误和风格不一致，可以根据规则集对代码进行静态分析。ESLint 可以帮助团队确保代码的质量和规范性。

Prettier：用于自动格式化代码，使其符合统一的代码风格。Prettier 可以消除团队成员之间关于代码格式的争论，确保代码风格的一致性。

Stylelint：类似于 ESLint，但专门用于检测 CSS、Less、Sass 等样式表文件中的问题。Stylelint 可以帮助团队维持一致的样式表编码风格。

Commitlint：用于检测 Git 提交信息的格式和内容，以确保提交信息遵循一致的规范。Commitlint 可以提高代码版本管理的可读性和维护性。

Husky：Husky 是一个 Git hooks 工具，可以在 Git 钩子事件发生时触发相应的操作。结合上述工具，Husky 可以用于在代码提交前运行 ESLint、Prettier、Stylelint、Commitlint 等检查，从而确保代码质量和规范性。

此外我们还添加了 sonar 代码检查工具并在提交上线发布单前做了强制拦截，它可以减少代码异味、重复率、复杂度等等。

CI/CD

持续集成和持续交付（CI/CD）:

持续集成（‌Continuous Integration）是一种软件开发实践，开发人员将代码频繁地提交到源代码管理系统中，这一过程中，自动化的测试和构建工具会自动从源代码库中获取最新的代码，进行编译、测试、打包等操作，并生成相应的构建产物。持续集成的目的是通过自动化手段提高软件交付效率，确保软件的高质量和快速迭代。它的核心措施包括在代码集成到主干之前，必须通过编译、代码扫描、安全扫描、自动化测试等，以确保软件的质量和稳定性。‌

CD（‌Continuous Delivery/Deployment）是在持续集成的基础上进一步发展的概念，它包含了持续交付和持续部署。持续交付指的是将构建产物部署到测试环境进行测试和验证，最终生成可部署的产物。而持续部署则是指将构建产物直接部署到生产环境，实现自动化的部署和发布，从而加快交付速度和迭代周期。

我们的部署流程是:

Jenkins -> Docker 镜像 -> k3s（轻量级的 Kubernetes）

CI 用的是开源的 Jenkins，它可以将源码、nginx 配置、node.js 等打包成镜像，由于 Docker Dockerfile 是前端自己编写的，所以执行脚本、nginx 配置、node.js 版本等都是前端可操作的，尽管这给了前端更大的自由度，但对于大多数工程来说这些其实是统一的，在工程中管理的必要性不大。此外由于前端仅仅是静态资源，其实并不需要每个工程都生成镜像和容器，所以这块还存在优化空间。

CD 主要用的是 k3s，它可以提供高效的容器编排和管理功能，创建高可用性集群。

开发、测试、预发、生产环境

我们一共有 4 个环境：本地开发环境、测试环境、预发环境、生产环境。

一般流程是在开发环境开发并自测，期间也会发布到测试环境上测试。大概上线日前一两天，会在测试环境上进行验收并提验收缺陷，缺陷都处理完毕后发布到预发环境，最后没有问题发布至生产环境完成上线。

组件库

组件库是基建中很重要的一部分，由于各个工程存在很多通用功能，通用功能随着需求的提出也会不断迭代，我们将这些功能封装成拓展性高的通用组件，从而避免了各自工程的重复建设，也提高了交互和体验的一致性。

组件库搭建我们使用的技术方案是： pnpm + vuepress + changeset。这套方案可以很好地支持组件的开发调试、多包管理、发版以及组件文档编写。

工具集

和组件类似，utils、WebpackPlugin、 vue 中的 directive、mixin 等很多也是通用的，我也进行了封装，这些我们组内统称为——工具集。

页面模板

页面模板是一些通用页面的集合，它是基于基础组件、通用组件、工具集等编写的页面，开发者开发通用页面时可以先一键复制页面模板的代码，再基于页面模板代码做业务修改。页面模板中的 UI 交互、代码都是严格符合规范要求的。

测试

为了保障组件、工具集等开发质量，我们引入了 jest 测试框架，良好的测试用例编写和维护其实并不容易，时间成本也很高，所以业务中广泛应用的必要性不大。

微前端

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。它的核心目标是将巨石应用拆解成若干可以自治的松耦合微应用，每个微应用具备独立开发、独立运行的能力。

由于历史原因，我们使用过 qiankun（react） 和 wujie（vue）两款微前端框架。

qiankun 原始配置上相对来说繁琐很多，不过主应用基座处理好后，并配合 umi 提供的 qiankun 配套插件，配置简化了很多。多层子应用路由嵌套和联动��在问题，我们使用相应方案进行了解决。我们所有应用都使用的 antd 并尽可能统一版本，所以基本没遇到过样式污染问题。

wujie 在配置上比较方便，可以像使用 iframe 一样方便嵌入子应用，路由无法联动的问题我们开发了对应的工具包（自动注册路由，监听事件和路由状态，自动处理路由跳转）进行了解决，多层嵌套失败的问题使用了统一域名代理得到解决。

目前这两款微前端框架满足了业务要求，其中的源码逻辑还是比较多的，除非有阻塞性问题，否则基本不会去动它。

静态资源管理

对于公共前端静态资源，我们使用了 webpack externals，让它们使用类似 cdn 链接的方式引入，从而尽可能利用缓存，提高页面加载速度（特别在微前端嵌入的时候），这些资源包括：vue/vue-router/vuex/tdesign/组件库/lodash/axios 等。

单点登录

我们登录使用的是公司统一的单点登录，同时在统一封装的 request 工具中会在每个请求的 Header Authorization 中携带上由后端根据登录信息生成的 token，从而实现鉴权。request 工具还具备取消请求、状态码统一处理、错误 message 提示等功能。

使用统计

对于组件、工具集使用情况，我们编写了 node.js 统计脚本，后端将该脚本部署到服务器上，拉取前端工程代码执行便可以获取到统计数据并存入数据库中，这部分数据再通过 BI 进行呈现。

对于模板使用情况，我们自己开发了统计接口（Next.js + Monogodb）进行了简单统计。

统一平台

我们在内网搭建了前端基建统一网站，所有前端基建相关的内容都可以在该网站上查找到，包括但不限于组件库、工具集、解决方案、前端规范、设计规范等。

未来可能会做的

自动化测试

通过录制脚本的方式来模拟手工测试，以确保主流程代码无破坏性修改。

埋点规范化

尽管有公司的埋点系统，但其实埋点并没有用起来，所以考虑将埋点与开发流程绑定，用埋点数据给产品迭代提供数据支撑。

监控系统

分为性能监控和错误监控，提供预警和问题追踪定位，提高产品质量和使用体验。

Mock

在后端接口未完成但文档已定义时，生成便于调试开发的 Mock 数据。

低代码探索

低代码并不容易，之前尝试做过低代码项目，但其实并不成功。核心问题在于当业务复杂了或定制化要求多了，低代码很难快速响应，要实现复杂功能如果设计的不充分极容易导致低代码难以维护，到头来还不如直接开发定制化页面来的便捷、体验更好呢，所以这方面还有待继续探索。