前端工程化
Posted by Mars . Modified at
前端工程化
前端工程化包括什么
前端工程化一般包括四个方面：模块化、组件化、规范化和自动化。
模块化、组件化
模块化就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。比如：CommonJS、ES6模块等。模块化是在文件层面上，对代码或资源的拆分。
组件化是在设计层面上，对用户界面的拆分。一个组件可能在页面上占据独立的一块，并且可以独立实现某项功能。
规范化
一般来说，前端规范化大体上可以分类为编码规范、开发流程规范和文档规范等，每个大类中又有一些子类，如编码规范中包含有目录规范、文件命名规范、js/css代码规范等。
自动化
工程自动化基本包含以下几方面内容:
- 图标合并
- 持续集成
- 自动化构建
- 自动化部署
- 自动化测试
前端工程化实操
技术选型
- 可控性
- 稳定性
- 适用性
- 易用性
规范化
JS、CSS规范
制定JS、CSS规范
找一份知名的代码规范（Js和CSS），根据团队实际进行个性化修改。
知名Js规范：
- airbnb 规范；
- standard 规范；
- 百度规范；
知名CSS规范：
- styleguide;
- spec;
检查规范
Eslint + stylelint + VSCode。
ESlint + Stylelint + VSCode自动格式化代码
Git规范
分支管理规范
一般项目分为master分支 + 其他分支。
开发新功能、修改Bug，都需要从master分支新开一个分支，命名后在新分支上修改，然后再合并到master分支。
commit规范
commit提交的信息格式如下：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
- 标题行 type: 描述主要修改类型和内容 （必填项）；
- 主题内容 body: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等；（选填项）
- 页脚注释 footer: 可以写注释，BUG 号链接。（选填项）
type
- 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 的链接.
示例
// git commit message.
feat(global): 添加网站主页静态页面
这是一个示例，假设对点检任务静态页面进行了一些描述。
这里是备注，可以是放BUG链接或者一些重要性的东西。
自动检查工具
使用husky工具进行检查。
husky基于git hooks，实现对commit、push前后对代码、commit message等进行检查。
项目规范
包括： 项目的目录结构和文件的命名方式。
项目目录结构一般包括：
- public： 公共资源，不会被打包；
- src：源码；
- test： 测试代码。
src代码中典型目录结构：
├─api （接口）
├─assets （静态资源）
├─components （公共组件）
├─styles （公共样式）
├─router （路由）
├─store （vuex 全局数据）
├─utils （工具函数）
└─views （页面）
UI 规范
前端、UI、产品沟通，互相商量，最后制定下来，建议使用统一的 UI 组件库。
自动化
测试
部署
部署项目，应该按如下步骤进行：
- 执行测试
npm run test； - 构建项目
npm run build； - 将打包好的文件，放置到服务器。
自动部署（又叫持续部署 Continuous Deployment，英文缩写 CD）一般通过监听webhook事件来实现。
