本文将分成以下 7 个小节：
- 技术选型
- 统一规范
- 测试
- 部署
- 监控
- 性能优化
- 重构
部分小节提供了非常详细的实战教程，让大家动手实践。
另外我还写了一个前端工程化 demo 放在 github 上。这个 demo 包含了 js、css、git 验证，其中 js、css 验证需要安装 VSCode，具体教程在下文中会有提及。
技术选型
对于前端来说，技术选型挺简单的。就是做选择题，三大框架中选一个。个人认为可以依据以下两个特点来选：
- 选你或团队最熟的，保证在遇到棘手的问题时有人能填坑。
- 选市场占有率高的。换句话说，就是选好招人的。
第二点对于小公司来说，特别重要。本来小公司就不好招人，要是还选一个市场占有率不高的框架（例如 Angular），简历你都看不到几个...
UI 组件库更简单，github 上哪个 star 多就用哪个。star 多，说明用的人就多，很多坑别人都替你踩过了，省事。
统一规范
代码规范
先来看看统一代码规范的好处：
- 规范的代码可以促进团队合作
- 规范的代码可以降低维护成本
- 规范的代码有助于 code review（代码审查）
- 养成代码规范的习惯，有助于程序员自身的成长
当团队的成员都严格按照代码规范来写代码时，可以保证每个人的代码看起来都像是一个人写的，看别人的代码就像是在看自己的代码。更重要的是我们能够认识到规范的重要性，并坚持规范的开发习惯。
如何制订代码规范
建议找一份好的代码规范，在此基础上结合团队的需求作个性化修改。
下面列举一些 star 较多的 js 代码规范：
css 代码规范也有不少，例如：
如何检查代码规范
使用 eslint 可以检查代码符不符合团队制订的规范，下面来看一下如何配置 eslint 来检查代码。
- 下载依赖
// eslint-config-airbnb-base 使用 airbnb 代码规范 npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import
- 配置
.eslintrc文件
{ "parserOptions": { "ecmaVersion": 2019 }, "env": { "es6": true, }, "parser": "babel-eslint", "extends": "airbnb-base", }
- 在
package.json的scripts加上这行代码"lint": "eslint --ext .js test/ src/"。然后执行npm run lint即可开始验证代码。代码中的test/ src/是指你要进行校验的代码目录，这里指明了要检查test、src目录下的代码。
不过这样检查代码效率太低，每次都得手动检查。并且报错了还得手动修改代码。
为了改善以上缺点，我们可以使用 VSCode。使用它并加上适当的配置可以在每次保存代码的时候，自动验证代码并进行格式化，省去了动手的麻烦。
css 检查代码规范则使用 stylelint 插件。
由于篇幅有限，具体如何配置请看我的另一篇文章ESlint + stylelint + VSCode自动格式化代码(2020)。
git 规范
git 规范包括两点：分支管理规范、git commit 规范。
分支管理规范
一般项目分主分支（master）和其他分支。
当有团队成员要开发新功能或改 BUG 时，就从 master 分支开一个新的分支。例如项目要从客户端渲染改成服务端渲染，就开一个分支叫 ssr，开发完了再合并回 master 分支。
如果改一个 BUG，也可以从 master 分支开一个新分支，并用 BUG 号命名（不过我们小团队嫌麻烦，没这样做，除非有特别大的 BUG）。
git commit 规范
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
大致分为三个部分(使用空行分割):
- 标题行: 必填, 描述主要修改类型和内容
- 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
- 页脚注释: 可以写注释，BUG 号链接
type: commit 的类型
- feat: 新功能、新特性
- fix: 修改 bug
- perf: 更改代码，以提高性能
- refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
- docs: 文档修改
- style: 代码格式修改, 注意不是 css 修改（例如分号修改）
- test: 测试用例新增、修改
- build: 影响项目构建或依赖项修改
- revert: 恢复上一次提交
- ci: 持续集成相关文件修改
- chore: 其他修改（不在上述类型中的修改）
- release: 发布新版本
- workflow: 工作流相关文件修改
- scope: commit 影响的范围, 比如: route, component, utils, build...
- subject: commit 的概述
- body: commit 具体修改内容, 可以分为多行.
- footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
示例
fix（修复BUG）
如果修复的这个BUG只影响当前修改的文件，可不加范围。如果影响的范围比较大，要加上范围描述。
例如这次 BUG 修复影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称。
// 示例1 fix(global):修复checkbox不能复选的问题 // 示例2 下面圆括号里的 common 为通用管理的名称 fix(common): 修复字体过小的BUG，将通用管理下所有页面的默认字体大小修改为 14px // 示例3 fix: value.length -> values.length
feat（添加新功能或新页面）
feat: 添加网站主页静态页面
这是一个示例，假设对点检任务静态页面进行了一些描述。
这里是备注，可以是放BUG链接或者一些重要性的东西。
chore（其他修改）
chore 的中文翻译为日常事务、例行工作，顾名思义，即不在其他 commit 类型中的修改，都可以用 chore 表示。
chore: 将表格中的查看详情改为详情
其他类型的 commit 和上面三个示例差不多，就不说了。
验证 git commit 规范
验证 git commit 规范，主要通过 git 的 pre-commit 钩子函数来进行。当然，你还需要下载一个辅助工具来帮助你进行验证。
下载辅助工具
npm i -D husky
在 package.json 加上下面的代码
"husky": { "hooks": { "pre-commit": "npm run lint", "commit-msg": "node script/verify-commit.js", "pre-push": "npm test" } }
然后在你项目根目录下新建一个文件夹 script，并在下面新建一个文件 verify-commit.js，输入以下代码：
const msgPath = process.env.HUSKY_GIT_PARAMS const msg = require('fs') .readFileSync(msgPath, 'utf-8') .trim() const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,50}/ if (!commitRE.test(msg)) { console.log() console.error(`
不合法的 commit 消息格式。
请查看 git commit 提交规范：https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md
`) process.exit(1) }
现在来解释下各个钩子的含义：
"pre-commit": "npm run lint"，在git commit前执行npm run lint检查代码格式。"commit-msg": "node script/verify-commit.js"，在git commit时执行脚本verify-commit.js验证 commit 消息。如果不符合脚本中定义的格式，将会报错。"pre-push": "npm test"，在你执行git push将代码推送到远程仓库前，执行npm test进行测试。如果测试失败，将不会执行这次推送。
项目规范
主要是项目文件的组织方式和命名方式。
用我们的 Vue 项目举个例子。
├─public ├─src ├─test
一个项目包含 public（公共资源，不会被 webpack 处理）、src（源码）、test（测试代码），其中 src 目录，又可以细分。
├─api （接口） ├─assets （静态资源） ├─components （公共组件） ├─styles （公共样式） ├─router （路由） ├─store （vuex 全局数据） ├─utils （工具函数） └─views （页面）
文件名称如果过长则用 - 隔开。
UI 规范
UI 规范需要前端、UI、产品沟通，互相商量，最后制定下来，建议使用统一的 UI 组件库。
制定 UI 规范的好处：
- 统一页面 UI 标准，节省 UI 设计时间
- 提高前端开发效率
测试
测试是前端工程化建设必不可少的一部分，它的作用就是找出 bug，越早发现 bug，所需要付出的成本就越低。并且，它更重要的作用是在将来，而不是当下。
设想一下半年后，你的项目要加一个新功能。在加完新功能后，你不确定有没有影响到原有的功能，需要测试一下。由于时间过去太久，你对项目的代码已经不了解了。在这种情况下，如果没有写测试，你就得手动一遍一遍的去试。而如果写了测试，你只需要跑一遍测试代码就 OK 了，省时省力。
写测试还可以让你修改代码时没有心理负担，不用一直想着改这里有没有问题？会不会引起 BUG？而写了测试就没有这种担心了。
在前端用得最多的就是单元测试（主要是端到端测试我用得很少，不熟），这里着重讲解一下。
