基建系列（一）

如何打造属于自己的前端基建

基建的意义

为什么要搞基建

在没有基建的情况下，相信大家都会有这样的一些经历：

• 团队代码风格不统一，团队成员相互觉得代码混乱且难以理解，很难合作；
• 每次新起项目时度需要再重复一遍之前的所有流程，浪费了大量的时间；而且反反复复的工作让人觉得乏味无趣；
• 项目越来越大，越来越复杂，没有一套自己的管理方式实在是难以维护，只能是屎山上加屎；
• 天天写业务代码，毫无长进，渴望搞搞架构成为大佬。

所以这个时候，一套属于自己或者团队的基建就显得格外重要。从起项目到发布，每一步都有自己的技术沉淀，即提升了自己的能力，又把自己从无休止的重新工作中解救出来。

基建的优势

编写前端基建的并非单纯地为了追求技术的先进性，而是为了解决项目在发展过程中所面临的一系列共性问题。 通过构建一套稳定、可靠的基础设施，开发团队能够更高效地专注于业务逻辑的实现，提高代码的可维护性和可扩展性，实现更高水平的性能和用户体验。

所以一套好的基建模版，应该有以下的一些优势（当然需要视情况而定，不一定要全部达到）：

• 自动化构建： 引入前端基建可以实现自动化的构建流程，包括代码编译、压缩、合并、版本控制等，减轻开发者手动操作的负担，提高项目构建的速度和准确性。

• 模块化开发： 利用前端基建工具，可以实现模块化开发，将大型项目拆分为小的可维护模块，提高代码的复用性和可读性。

• 代码规范检查： 集成代码规范检查工具，确保团队成员遵循一致的编码规范，减少代码质量波动，提高整体代码质量。

• 自动化测试： 引入前端基建可以实现自动化测试，包括单元测试、集成测试和端到端测试，确保代码的稳定性和可靠性。

• 版本管理： 使用前端基建工具可以轻松管理项目的版本，方便回滚、发布和升级，确保团队在不同阶段都能够使用稳定的代码版本。

• 性能优化： 集成性能分析工具，实现自动的性能优化，包括资源压缩、懒加载、缓存等，提高页面加载速度和用户体验。

• 错误监控与日志： 引入前端基建可以集成错误监控和日志记录工具，及时捕获和分析线上错误，提高排错效率。

• 跨浏览器兼容： 利用前端基建工具进行代码打包和转译，确保项目在不同浏览器中的兼容性，提高项目的可用性。

• 可扩展性： 前端基建工具提供了丰富的插件和配置选项，可以根据项目的需求进行定制，保证项目的可扩展性。

• 团队协作： 统一的前端基建工具链能够促进团队协作，减少不同开发者之间的差异，提高整体开发效率。

基建的方向和重点

方向从何而来

按照我的构想，一个相对完善的研发流程包括以下步骤：

**

需求阶段

**

• 需求录入
• 需求分析

**

规划阶段

**

• 技术方案确定
• 任务分解与分配

**

开发阶段

**

• 自动化创建和分配代码仓库与分支权限
• 本地开发和自测

**

测试阶段

**

• 自动化部署测试环境
• 测试并修复 bug

**

灰度发布

**

• 提交灰度请求
• 自动化打包部署灰度

**

生产发布

**

• 提交生产环境部署请求
• 自动化部署生产环境

**

监控与运维

**

• 设置监控与报警机制
• 处理线上问题

**

数据分析

**

• 数据收集
• 数据分析

**

文档总结

**

• 形成最终的需求文档、技术文档和团队文档

**

迭代优化

**

• 根据数据分析和监控结果进行系统和流程的优化

这一套流程强调自动化，强调流程的完整性，我们的基建方向，就应该来源于这些流程中的关键点。 举一个例子，上面说的自动化部署，就可以利用 gitlab 的 CI/CD 功能完成自动化部署，通过对分支名字的判断，触发部署不同的环境。

重点如何确定

我个人大小公司都待过，个人觉得基建的重点来源于团队的构成。

• 大厂: 人员充足，流程上应该尽量自动化；业务稳定，那么提高客户满意度应该是首位，那么数据分析也是最为重要的一环；流动性大，那么文档的建设必须非常完善。
• 小公司: 主要精力在于提高效率完成项目需求，主要工作量都是在代码方面，所以脚手架，组件库等是更好的侧重点。

具体搞那些基建

我针对自己搞过的基建以及感兴趣的方向，总结了一下我觉得应该侧重的基建方向

**

开发规范

**

• 校验规范：eslint、prettier 以及 vscode 的 setting.json(包括本地和工作区) 需要先行，所有人用同一套的规范，需要兼容 window 和 mac 等；
• 书写规范：各类文件名的命名方式、内部方法和参数的命名方式、接口的发送和请求数据结构等；
• 提交规范：git 提交的说明需要根据具体的提交填写，比如 feat 开头表示开发新功能，fix 开头带边修复 bug；
• 分支规范：一定要设置保护分支，防止不熟悉的人乱提交合并，同时给每个人设置具体的权限；无权限者需要提 MR 给有权限者进行代码合并；同时分支命名需要注意，最好加上版本号和开发者名称等可以明显区分的信息；

**

文档规范

**

文档种类太多，列出一些常见的文档如下：

• 新人文档
• 需求文档
• 技术文档
• 业务文档
• 项目文档
• 技术交流分享文档

**

脚手架

**

现在前端应用方向有客户端、web 端、小程序等，如 web 端又有 Vue、react、angular 等框架，打包工具又有 vite、webpack 等，再加上一些其他的 npm 包，简单地乘一下这量就上来了。 我们哪有那么多精力去学习每一个框架、工具、应用场景的搭建和用法呢，自己搭的话，每个人的理解和配置都不一样，而且费时费力，所以弄一套脚手架工具就至关重要。 大家通过这一套脚手架，只需要 1 分钟，几行命令、几个选择就可以搭建好一个项目，而且这些项目的配置如 eslint、prettier、tsconfig.ts、vite.config.ts 等都不需要再额外配置，这脚手架，多是一件美事啊。

**

组件库

**

一个公司的 UI 风格应该是大差不差的，所以每个项目用同一套组件库完全没毛病。 考虑到市面上的组件库如 ant design, element-plus 等都是基础组件，有时候并不能完全满足我们的需求，很多公共的组件都需要重新封装，那就可以搞一套自己的组件库，所有项目都可以共享，避免重复的工作。 当然，如果想要开源，那就按照现有的组件库参考自己开发吧，哈哈哈。

**

镜像库

**

每个人都被安装 npm 包时折磨过把，国内使用实在是太慢了太慢了。 所以如果你的网络不好或者有限制，搭建自己的镜像库就非常合适。只要设置自动化命令让镜像库每隔一段时间同步一下 npm 源就行了。

**

工具函数库

**

写了那么多公共方法，都放到 utils 里面了，结果下一个项目用了一半，那么我就只能调出这一半复制到下一个项目里，累啊。 开发一个工具函数库吧，不求一开始就达到 lodash 那种复杂度，慢慢完善，积少成多吗。

**

CI/CD 自动化部署

**

手动部署存在很多潜在问题，包括复制粘贴、手动配置文件、潜在的人为错误等，这不仅浪费时间，也增加了出错的概率。因此，自动化部署成为解决这一问题的重要方式。 在这一过程中，使用 CI/CD 工具（如 GitLab CI）可以极大提高效率。通过配置简单而强大的 gitlab-ci.yml 文件，我们可以实现提交代码后的自动构建、测试和部署。这个过程不仅可以根据分支名字区分不同环境，还能够通过设置参数执行一些特殊操作，使整个部署过程更加灵活。 这种自动化部署的好处不仅在于提高了部署速度，还在于降低了人为出错的可能性。即使是新成员加入，只需了解一下 CI/CD 的配置文件，就能够轻松理解和参与到自动化部署流程中。这样团队可以更专注于开发和创新，而不是花费大量时间在手动部署和错误排查上。

**

数据埋点

**

数据埋点是通过在应用程序代码中插入代码片段，跟踪用户在应用内的操作。这些操作可以包括页面浏览、按钮点击、表单提交等。数据埋点的目的是收集丰富的用户行为数据，为后续分析提供基础。 收集到的数据通过分析工具进行处理和解读。这些工具能够帮助我们了解用户的习惯、喜好以及在应用中的痛点。通过分析数据，我们可以发现用户的转化路径、瓶颈所在，并作出相应的优化措施。 下面是一些数据类型：

• 行为数据：时间、地点、人物、交互、交互的内容；
• 质量数据：浏览器加载情况、错误异常等；
• 环境数据：浏览器相关的元数据以及地理、运营商等；
• 运营数据：PV、UV、转化率、留存率（很直观的数据）；

**

微前端

**

微前端的初衷是为了解决老旧项目难以维护，技术落后的问题，而现在也扩展到由小项目聚合成大项目，每个小项目专注于单一的功能，解决各个团队技术栈不一致、各个团队沟通成本等问题。 微前端目前比较流行的框架如下，这也是我用过的几个微前端框架：

• qiankun: 基于 single-spa ，阿里系开源的微前端框架，应该也是大家接触最多的了，社区比较活跃，这点比较重要。
• Micro-App：Micro App 是京东出的一款基于 Web Component 原生组件进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率
• 无界：无界是腾讯推出的一款微前端解决方式。它是一种基于 Web Components + iframe 的全新微前端方案，继承 iframe 的优点，补足 iframe 的缺点，让 iframe 焕发新生。

**

pnpm + Monorepo 的单仓多包工程结构

** Monorepo 是指在单一版本控制仓库中管理多个项目的软件开发模型。优势在于能够更容易共享代码、依赖管理、版本控制和跨项目的协同开发 pnpm 使用一种称为“逻辑链接”的方法，将依赖项链接到项目中，而不是将它们复制到每个项目中。这种链接的方式能够在系统中共享依赖项，从而减少磁盘空间的使用，并提供更快的安装和运行时。

遇到巨石项目或者多项目相互依赖的情况怎么办，总不能改造成微前端吧，这也太浪费了，要知道，微前端的通信是很复杂的，而且微前端主要还是解决技术栈和团队协作问题啦。 所以这个时候，monorepo 模式就非常契合了，他的单仓多包模式就能够完美解决这个问题。再搭配上以及支持 monorepo 的 pnpm，完美解决项目分割和项目互相依赖引用的问题。

常见的使用这种模式的项目场景如下：

• 前端框架Vue
• 原子化样式方案UnoCss
• UI 组件库，如 Element-plus
• 设置多端的 web 项目

说在最后

搞基建是一个很麻烦很复杂也很累的事情，但是呢也是实现自己的额外价值（可以理解为卷绩效），提升自己能力和竞争力的一种方式，甚至也是偷懒的一种方式（毕竟从重复的工作中解放了出来），所以呢，有空的话搞一搞还是很有必要的。 基建有时候会涉及不属于自己领域的知识，很多人会在经历挫折后就放弃，但是我想说的是，搞基建是一个循序渐进的过程。不求一开始就完美，一点点来，一点点完善即可，那个主流技术没有迭代几十个版本的对不对，所以坚持吧， 坚持地搞下去，才能有自己的技术沉淀啊，我之前经常性地被一个问题搞一两天，甚至好几天呢，所以遇到问题安啦。