之前被问什么是工程化，有点迷糊，后虚心请教：“工程化就像建房子一样，比如要先有基地，要怎么建，都有一个标准、规划性的东西......比如现在eslint编码规范要求或者是开发模块规范，在之前前端都是没有这种划分的的。。。。。。巴拉巴拉”，恍然大悟呀。于是去学习了下，整理了下目前能做的实在点。
用一张图来表示：
一、开发
1. 组件库-业务组件化
组件库，小团队一般直接用andt或者是element，大公司会有专门的公司内部组件库。对于项目而言，需要做的是提取出业务化的组件。
2. 模块化-按照模块划分文件夹
在开发过程中，应按照功能模块划分文件夹，而不是以菜单作为文件，举个简单的例子，
场景： test菜单页和user菜单页，有公共组件，但是它不是全局的只有在A模块内。
不合理❌：
└── compontents📂
└── A模块公用组件
└── ...
└── pages
└── test
├── test.tsx
└── compontent
└── user
├── user.tsx
└── compontent
按照菜单划分：把它写在compontents📂全局组件上是不合适的，因为那个组件可能需要请求数据，这时候就要把业务请求写在全局的公共组件文件夹里（或者是说再从pages里面引进请求），这就没有公用组件的意义了，并且非常奇怪。
合理✔：
└── compontents📂
└── pages
└── A模块
└── A模块公用组件
└── test
├── compontent
└── test.tsx
└── user
├── compontent
└── user.tsx
按照模块划分：全局的就全局组件，模块内的组件共用模块化内的组件，页面内的组件作为页面内的组件，做到组件和业务隔离，引用关系也很明了。
3. 技术选型
技术选型大到技术栈，再到脚手架，小到依赖包等。
个人认为主要有以下几个点：
- 能否满足现项目的需求，也是必须的。
- 选用的技术栈（组件库UI、脚手架等）是否还有在维护，文档是否齐全，市面上是否有成功的案例参考，或是start的数量，npm包下载量都是可以参考的，对于不明确的地方试下demo，确保项目开发过程中不会出现发现有些功能做不了了。
- 团队现有技术的储备，团队人员的技术也是参考范围之一，以及学习成本还有开发成本。
二、构建
- 静态资源等文件压缩
- 代码分割
- 构建优化
三、发布部署
- 持续部署-自动化 Jenkins
- nginx
- docker-容器化
- 静态资源部署策略
四、规范
1、git规范
commit提交规范
- 尽量小颗粒度提交代码，即多commit
- 根据编写的代码给commit增加提交类型前缀：
| 前缀 | 说明 |
|---|---|
| feat | 新功能或模块时候用 |
| fix | 解决bug时候 |
| style | 只修改样式，无修改逻辑 |
| docs | 只修改文档时候 |
| refactor | 重构时候 |
| merge | 合并代码时候 |
| revert | 回退回滚版本时候 |
版本分支命名规范化：
| 分支 | 说明 | 必要 |
|---|---|---|
| master主分支 | 作为给用户提供的分支同步线上，不能在该分支上做直接开发 | 是 |
| develop | 作为开发分支，包含开发的最新功能，用于合并，不能在该分支上做直接开发 | 否，视项目而定 |
| feature | 用于新版本迭代，功能在此开发 | 是 |
| hotfix | 紧急bug解决 | 是 |
例如，新版本迭代分支：feature/v1.20；运营提了一个线上用户bug需要紧急修复分支：hotfix/v3.10
代码审核code review：Gerrit
需不需要？视情况而定，这个我们团队在使用过程中并没有感觉很大的好处。
2、项目开发编码规范
//todo
有些地方需要遵守特定规范，有些地方需要做标准的规划设计流程，在这些“约束”条件下怎么方便怎么来，这种工程化才真正以利于个人和团队的协作开发。
