前言赘述：
复制下哉ZY课呈：https://www.sisuoit.com/2764.html本文将分成以下 7 个小节：
- 技术选型
- 统一规范
- 测试
- 部署
- 监控
- 性能优化
- 重构
部分小节提供了非常详细的实战教程，让大家动手实践。
另外我还写了一个前端工程化 demo 放在 github 上。这个 demo 包含了 js、css、git 验证，其中 js、css 验证需要安装 VSCode，具体教程在下文中会有提及。
技术选型
对于前端来说，技术选型挺简单的。就是做选择题，三大框架中选一个。个人认为可以依据以下两个特点来选：
- 选你或团队最熟的，保证在遇到棘手的问题时有人能填坑。
- 选市场占有率高的。换句话说，就是选好招人的。
第二点对于小公司来说，特别重要。本来小公司就不好招人，要是还选一个市场占有率不高的框架（例如 Angular），简历你都看不到几个...
UI 组件库更简单，github 上哪个 star 多就用哪个。star 多，说明用的人就多，很多坑别人都替你踩过了，省事。
统一规范
代码规范
先来看看统一代码规范的好处：
- 规范的代码可以促进团队合作
- 规范的代码可以降低维护成本
- 规范的代码有助于 code review（代码审查）
- 养成代码规范的习惯，有助于程序员自身的成长
当团队的成员都严格按照代码规范来写代码时，可以保证每个人的代码看起来都像是一个人写的，看别人的代码就像是在看自己的代码。更重要的是我们能够认识到规范的重要性，并坚持规范的开发习惯。
如何制订代码规范
建议找一份好的代码规范，在此基础上结合团队的需求作个性化修改。
下面列举一些 star 较多的 js 代码规范：
- airbnb (101k star 英文版)，airbnb-中文版
- standard (24.5k star) 中文版
- 百度前端编码规范 3.9k
css 代码规范也有不少，例如：
- styleguide 2.3k
- spec 3.9k
如何检查代码规范
使用 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 的链接.
