目錄
- 工具簡介
- 實現思路
- 具體實現
- 總結
- 附錄
代碼千萬行，規范第一行。
編碼不規范，同事兩行淚。
早幾年接手過一個項目，一堆bug不說，代碼還又臭又長，據說之前寫代碼的那位仁兄經常改一個bug又帶出十個bug🌝項目里充斥着各種含義不明的變量、沒有用到的不知道從哪里復制粘貼過來的函數、亂七八糟的console、隨心所欲的空行和毫無意義的注釋……
很多程序員沒有代碼規范意識，經常覺得只要功能能用就行了，代碼規范浪費時間，於是寫出來的代碼過一段時間可能連自己都看不懂是坨什么東西，更不用說接手的同事了。
今日便來說說，如何從技術層面，實現代碼規范以及代碼提交規范。
1、工具簡介
- husky：一個Git hooks工具，可以讓我們在git提交前后進行一些操作，比如，在提交之前檢查代碼是否規范、進行統一的格式化處理、檢查git提交的信息格式等等；
- eslint：一個用NodeJS寫的Javascript代碼檢查工具，可自定義規則；
- lint-staged：一個能夠只對git變更文件進行代碼檢查的工具；
- commitizen：一個提供了交互式命令，可用於規范git commit信息的工具。
以上就是我們這次要用到的四個工具。
2、實現思路
我們可以通過husky提供的鈎子(hooks)：
-
在git提交前，使用eslint或者lint-staged對代碼進行檢查，並進行統一的格式化處理；
-
在git提交時，檢查git commit的格式是否符合規定；同時，使用commitizen實現命令行交互，來輔助我們生成合規的git commit。
3、具體實現
3.1 husky
安裝：
yarn add husky -D
在package.json的script中添加：
"scripts": {
"prepare": "husky install"
}
prepare是npm的生命周期腳本。
當執行npm install的時候，就會自動執行腳本內容husky install，從而在當前項目的根目錄下生成.husky文件夾。
這里的husky.sh配置主要是為了獲取hook的執行結果，當執行過程中出錯時，就退出進程。
接下來就可以愉快地使用git hooks啦。
3.2 hook：pre-commit
命令行執行yarn husky add .husky/pre-commit生成pre-commit腳本（當然也可以手動）：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
undefined
稍作修改，來驗證下在git commit的時候是否執行了這個腳本：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "commit之前執行"
命令行git提交代碼：
git add .
git commit -m”add husky config”
可以看到pre-commit腳本執行成功，打印出了語句。
3.3 在pre-commit里添加eslint檢查
安裝：
yarn add eslint —dev
安裝完成后，執行
yarn run eslint —init
或
./node_modules/.bin/eslint —init
執行完成后會自動在根目錄生成eslint配置文件.eslinttrc.js。
修改pre-commit，添加eslint格式檢查：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "eslint格式校驗" && ./node_modules/.bin/eslint src/*
可以看到，eslint檢測出代碼里有2個error和1個warning。
error是必須修改的，可以使用eslint --fix自動修復，並執行git add .把fix后的變更也添加到git緩存區：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "eslint格式校驗"
./node_modules/.bin/eslint src/* --fix # 對src下的所有文件作eslint檢查，並用--fix修復error
git add . # 將eslint的fix內容也添加到git提交中
測試一下：
成功！
提示：如果使用的是Github Desktop這類的圖形工具，有可能會出現下面這個錯誤——
這是因為我們只在項目里安裝了eslint，當在軟件上運行的時候就有可能出現路徑錯誤，只需要全局安裝一下eslint就可以了：
yarn add eslint -g
上面的eslint檢查腳本會對src中的所有文件進行檢查。如果是一個新項目還好，如果是一些老項目，那么涉及到的變更文件就會很多。
如果不想每次都全量檢測，那么可以通過git diff來獲取到變更的文件：
修改pre-commit：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "eslint格式校驗"
arr=`git diff --name-only HEAD` # 查看變更文件
for filepath in ${arr[@]}
do
if [[ "$filepath" =~ ^[src/] ]]; then : # 只檢測src下被修改的文件的格式
if [ -f "$filepath" ];then # 只對存在的文件進行fix，跳過delete的文件
echo $filepath
./node_modules/.bin/eslint $filepath --fix
git add $filepath
fi
fi
done
這段代碼實現了：只對src中有變更且非刪除的文件進行eslint檢查和fix。
這里推薦一個工具，也就是上面提到的lint-staged，也能實現同樣的功能，使用起來更簡單。
執行npx mrm@2 lint-staged，可以看到package.json中多了關於lint-staged的配置：
修改一下：
"lint-staged": {
"src/*": "eslint --fix"
}
pre-commit改為：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
echo "eslint格式校驗"
npx lint-staged
測試一下：
成功！
至此，我們就實現了基本的代碼規范配置。
eslint的詳細配置參數這里就不展開了，感興趣的同學可以去官網上自行探索。
3.4 用commitizen規范git commit
安裝：
npm install --save-dev commitizen
在package.json中配置：
"scripts": {
"commit": "cz"
},
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}
測試一下：
注意，這里就不能用git commit了，而要用yarn run commit或npm run commit，執行后命令行里會出現一些交互選項，來幫助我們生成git commit。
看不習慣英文的也可以安裝中文包：
yarn add cz-conventional-changelog-zh
commitizen只能幫助我們生成規范的git commit，如果有些隊友忘了使用yarn run commit，而直接用git commit -m”xxx”寫了不規范的提交信息，怎么辦？
還記得上面說的husky嗎？我們可以通過husky的commit-msg鈎子來校驗git commit的提交信息。
3.5 hook：commit-msg
yarn husky add .husky/commit-msg
修改commit-msg：
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
commit_regex='^Merge.+|(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types)(\(.+\))?: .{1,50}'
if ! grep -iqE "$commit_regex" "$1"; then
echo
echo "commit信息格式錯誤！！"
echo "格式應為：[Type]: [Summary]"
echo "Type可選值為Merge|feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types"
echo "注意中間的空格"
echo "示例：git commit -m \"test: add something test\""
echo
exit 1
fi
測試一下：
大功告成！
4、總結
規范的代碼不僅能減少合並沖突，還有助於提高代碼的可讀性，降低之后的維護成本。
對團隊而言，有可能是鐵打的代碼流水的程序員，前人留下的坑得后人去填，規范代碼是非常必要的。
對個人而言，規范的代碼不僅能減少bug的出現，還有助於更好地理解編程語言的特性，成長有時候就是這些細節處的積累。
技術上只能起到一部分的規范作用，更重要的還是意識上的主觀能動性，只有意識到代碼規范的重要性，才能真正實現項目的代碼規范化。