具备基本工程素养的同学都会注重编码规范，而代码风格检查（Code Linting，简称 Lint）是保障代码规范一致性的重要手段。
使用 Lint 会有什么好处呢？在我看来至少具有如下 3 点：
- 更少的 Bug
- 更高的开发效率，Lint 很容易发现低级的、显而易见的错误
- 更高的可读性
- 很多时候我们lint的校验是放在持续集成阶段，大概流程如下：
代码提交 --> 跑 CI 发现问题(远程) --> 本地修复问题 --> 重新提交 --> 通过检查(远程)
但这样有一个问题，我们的 CI(持续集成) 往往不是仅仅只做 Lint工作，它还有会有很多其它的任务（如打包文件，静态资源上传 CDN 等），这样就导致特别的浪费时间，往往可能需要几分钟之后你才会发现问题，或者有的时候你根本就没有发现你的 CI 没有跑通过。
常见的流程：本地写好了代码，提交，开始跑 lint，发现不通过，本地修改代码，再提交，再等待 CI 的结果，若还有问题再重复之前的操作。
husky 为 git commit 增加钩子
在之前的工作中，我们尝试通过在 git 的 pre-receive 阶段嵌入一系列的 ci 流程处理代码以提供给开发者们 "just push" 的开发流程（当然这个想法是完完全全源自 heroku 的）。这个流程将原先的 "push -> wait for verify -> new correct commit -> repush" 的流程转变为 "push -> fail -> correct -> repush"：如果没有在 "pre-receive" 阶段设置门禁的话，坏的提交会被同步到中心仓库后在进行检测；而设置门禁之后坏的 commit 会被拒绝在本地，本地只能将 ci 可以通过的代码提交到中心仓库。但是将所有东西都通过 push 验证很显然是慢了一些：这就像表单的前端验证和后端验证一样，虽然后端验证永远必不可少但是它增加了服务器的负担并且延长了反馈周期。
这时候 husky 就要派上用场了。husky 其实就是一个为 git 客户端增加 hook 的工具。将其安装到所在仓库的过程中它会自动在 .git/ 目录下增加相应的钩子实现在 pre-commit 阶段就执行一系列流程保证每一个 commit 的正确性。部分在 cd commit stage 执行的命令可以挪动到本地执行，比如 lint 检查、比如单元测试。当然，pre-commit 阶段执行的命令当然要保证其速度不要太慢，每次 commit 都等很久也不是什么好的体验。
在项目根目录下安装
yarn add --dev husky lint-staged
修改package.json文件
"husky": {
"hooks": {
"pre-commit": "lint-staged",
}
},
"lint-staged": {
"*.{js,vue}": [
"eslint --fix",
"git add"
]
},
如上配置，每次它只会在你本地 commit 之前，校验你提交的内容是否符合你本地配置的 eslint规则，如果符合规则，则会提交成功。如果不符合它会自动执行 eslint --fix 尝试帮你自动修复，如果修复成功则会帮你把修复好的代码提交，如果失败，则会提示你错误，让你修好这个错误之后才能允许你提交代码。
优雅的提交你的Git Commit Message
在项目根目录下安装
yarn add --dev @commitlint/cli @commitlint/config-conventional
在项目根目录下新建.commitlintrc.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'subject-case': [0, 'never'],
'type-enum': [
2,
'always',
[
'build', // 构建
'ci', // ci
'chore', // Other changes that don't modify src or test files. 改变构建流程、或者增加依赖库、工具等
'docs', // Adds or alters documentation. 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
'feat', // Adds a new feature. 新增feature
'fix', // Solves a bug. 修复bug
'perf', // Improves performance. 优化相关，比如提升性能、体验
'refactor', // Rewrites code without feature, performance or bug changes. 代码重构，没有加新功能或者修复bug
'revert', // Reverts a previous commit. 回滚到上一个版本
'style', // Improves formatting, white-space. 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
'test' // Adds or modifies tests. 测试用例，包括单元测试、集成测试等
]
]
}
}
修改package.json文件
"husky": {
"hooks": {
...
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
这样，每次提交都会检测message信息，如果不符合要求，则提交不成功。
prettier 保证每个团队代码格式一致性
多少年来开发者在使用 tab 还是 space 的问题上真是花费了不少的时间，美剧硅谷里主角还因为 tab 和别人闹了一集，可见大家对代码格式化的重视程度-_-。记得我在上一个项目里看到有小哥把我的代码强行刷成他满意的格式的 commit 也非常不满。仅仅修改格式的 commit 是毫无必要的，它没有对软件本身的行为做任何的修改，而夹带了修改格式的 commit 更是令人抓狂的，给 review 的同学也带来了不小的负担（在一坨提交里仔仔细细看了半天发现神马也没变！！尼玛！！）。
golang 取了个巧，语言自带官方格式，你们终于不吵了吧。虽然会有时候看 golang 的格式化结果略微有点麻烦（就是 struct 对 json type 的制表符对齐的要求），但是也没有哪里是让人无法忍受的丑。如果其他的语言也以类似的方式制定一个官方格式是不是就会将此事平息下去呢。当然，我们可以在制定这个官方格式的时候吵架，只要官方格式不会三天两头的更新那在实际项目中为这种不必要的分歧导致浪费大把时间了。
在我看来 prettier 就是这么一个 "类官方格式" 了。不过目前它还只是支持 js 体系下的格式化，其他语言由于这样那样的问题还要再等等。
大家对有个公认的格式这件事还是非常认可的，项目出现一年，Github star 破 2.1w，并且像 facebook 这样的大公司已经在内部逐渐铺开使用了。
集成
最后，通过 husky 为 prettier 在 pre-commit 加个钩子，这体验就更完美了：不论你家的格式是什么样子，只要你想提交，就必须格式化成 prettier 要求的样子，这样就没有那种因为格式变动出现的无聊的 diff 了。集成的流程基本是以下这个样子：
-
添加 prettier 依赖
yarn add prettier --dev --exact -
测试格式化是否工作
yarn prettier -- --write src/index.js -
在 commit 时执行 prettier
yarn add pretty-quick husky --dev修改
package.json添加 pre-commit 钩子{ "scripts": { "precommit": "pretty-quick --staged" } }
其实官方文档也有，但是官方文档可耻的写错了...第二步命令少了 -- 的命令。
最后的最后，放一段 prettier 格式化的 react 代码，我还是对其默认的格式非常满意的。
class Badges extends React.Component {
componentDidMount() {
let { user, loadBadges } = this.props;
loadBadges(user.username);
}
render() {
let { badges } = this.props;
return (
<div style={{ marginTop: "50px" }}>
<h1>已经获得的成就</h1>
<Row
gutter={16}
type="flex"
justify="center"
align="top"
style={{ marginTop: "20px", paddingBottom: "10px" }}
>
{badges.map(badge => (
<Col
lg={6}
md={6}
sm={8}
xs={12}
style={{ marginBottom: "1em" }}
key={badge.project.id}
>
<ProjectBadge badge={badge} />
</Col>
))}
</Row>
</div>
);
}
}
