作者:山月行 全棧成長之路
轉發鏈接:https://mp.weixin.qq.com/s/YPErjYubpM6WFrsCPcR3CQ
前言
一千個讀者,就有一千個哈姆雷特。
一千個程序員,就有一千種代碼風格。
那什麼是代碼風格呢?從小的來說,有的開發喜歡帶分號,有的不喜歡帶分號。有的喜歡使用空格,有的喜歡使用 Tab。有的喜歡空兩個空格,有的喜歡四個空格。除了這些,還有一些關於代碼的優化,如避免聲明未使用,避免冗餘的代碼邏輯等。如果你是新參加工作的人員,又恰好遇到一個代碼風格混亂,密密麻麻賦值前後都不帶空格的項目,只能有苦難言了。
因此團隊合作中需要統一規範。
小編強烈推薦前端規範文章:
《前端開發規範:命名規範、html規範、css規範、js規範》
ESLint 與約束
統一編碼規範不僅可以大幅提高代碼可讀性,甚至會提高代碼質量。當我們設計了一套關於編碼規範的規則集時,需要工具去輔助檢測,這就是 ESLint。
<code>$ npminstall
eslint /<code>
規則集需要統一集中配置,ESLint 會默認讀取配置文件 .eslintrc 來解析,而規則集在 rules 中進行配置:
<code>{"rules"
: {"semi"
: ["error"
,"always"
],"quotes"
: ["error"
,"double"
] } }/<code>
而我們需要做的是設定我們的代碼規範,即 rules 項,關於它的文檔及最佳實踐參考下文:
- ESLint Rules and Best Practices[1]
不要重複造輪子
我們需要推倒重來,設計屬於自己團隊的一套編碼規範嗎?
完全沒有必要推倒重來,既耗費人力,又難以做到規則的全部覆蓋。
很多優秀的團隊,都根據最佳實踐設定了特別優秀的編碼規範,比如 airbnb 設定了一套約束特別強的規範。另外也有一些特別簡單但卻十分實用的規範,如 eslint:recommended。
- airbnb javascript style[2]
我們僅僅需要使用 extend 配置項去繼承一些優秀的開源的代碼規範,並使用 rules 做一些自己團隊的規則補充。
<code>{"extend"
: ["airbnb-base"
],"rules"
: {"semi"
: ["error"
,"never"
] } }/<code>
開發環境,生產環境與警告
開發環境對於開發而言重要的是什麼?
是開發體驗。
一個良好的編碼規範會帶來解放強迫症的舒適感,但過於嚴格的代碼風格有時也會使人煩躁。試舉兩個小例子,有可能是在你寫代碼時出現過的場景:
- 禁止掉 console.log,避免在生產環境輸出多餘的東西。但偏偏在測試環境經常需要調試,但是如果僅僅設為警告的話,警告又會被忽視,失去意義。
- 特別是當設置了規則 no-unused-vars 時。如果僅僅是為了在開發時調試,卻因為無法通過 ESlint 規則校驗無法方便調試。
這是一個約束與自由的權衡,ESLint 在提供強有力約束時自然會犧牲一些開發商的便利性。中庸,儒家思想講究中庸,此時可以在權衡下選擇一箇中庸的方案:
把 ESLint 的所有影響調試的規則校驗都設置為 Warn,那你又問了警告往往不是會被忽略嗎?是這樣子的,所以需要在 CI 中設置環境變量 CI=true,如此在 CI 中即使有警告也無法交付。CI 指持續集成,在本篇文章後邊也會接著提到,另外,在本系列文章中也會重點講解 CI,歡迎持續關注。
如在 create-react-app 中的大部分規則都是設置為 Warn
但是,如果你使用了 webpack,並且結合 eslint-loader,那解決方案就更加簡單了:使用 emitWarning: true,在測試環境把所有 Error 都當做 Warn,這樣避免了修改 ESLint 規則,webpack 的配置如下
<code>{
test:
/\.(js|mjs|jsx|ts|tsx)$/,
enforce:
'pre'
,
use:
[
{
options:
{
cache:
true
,
emitWarning:
true
,
},
loader:
require.resolve('eslint-loader'),
},
]
}
/<code>
所以有兩種權衡開發體驗與編程規範的方式:
- 把 ESLint 的 rule 設置為 Warn,並在持續集成中配置環境變量 CI=true。
- 結合 webpack 與 eslint-loader,根據當前環境的環境變量配置 emitWarning。
第一層約束: IDE
當不符合代碼規範的第一時間,我們就要感知到它,及時反饋,快速糾正,比直到最後積攢了一大堆錯誤要高效很多。
這裡以 VS Code 作為示例,它只需要安裝一個插件:eslint,便可以做到智能提示,來看看效果吧:
另外,配合 eslint-loader,使用瀏覽器也可以做到實時提示:
第二層約束: Git Hooks
團隊合作中的編碼規範有一點是,雖然自己有可能不舒服,但是不能讓別人因為自己的代碼而不舒服。
git 自身包含許多 hooks,在 commit,push 等 git 事件前後觸發執行。與 pre-commit hook結合可以幫助校驗 Lint,如果非通過代碼規範則不允許提交。
husky[3] 是一個使 git hooks 變得更簡單的工具,只需要配置幾行 package.json 就可以愉快的開始工作。
husky 的原理是什麼?
<code> {"scripts"
: {"lint"
:"eslint . --cache"
},"husky"
: {"hooks"
: {"pre-commit"
:"npm lint"
, } } }/<code>
或者結合 lint-staged[4] 調用校驗規則
<code>{"husky"
: {"hooks"
: {"pre-commit"
:"lint-staged"
} },"lint-staged"
: {"*.js|{lib,setup,bin,hot,tooling,schemas}/**/*.js|test/*.js|{test,examples}/**/webpack.config.js}"
: ["eslint --cache"
],"*.{ts,json,yml,yaml,md}|examples/*.md"
: ["prettier --check"
],"*.md|{.github,benchmark,bin,examples,hot,lib,schemas,setup,tooling}/**/*.{md,yml,yaml,js,json}"
: ["cspell"
] } }/<code>
不過做前端的都明白,客戶端校驗是不可信的,通過一條命令即可繞過 git hooks。
<code>$ git commit -n/<code>
第三層約束: CI
git hooks 可以繞過,但 CI(持續集成) 是絕對繞不過的,因為它在服務端校驗。使用 gitlab CI 做持續集成,配置文件 .gitlab-ci.yaml 如下所示
<code>lint
:stage
:lint
only
:/^feature\/.*$/
script
:npm lint
/<code>
小結
- 團隊中代碼規範統一是極有必要的
- 使用成熟的 eslint config,並做細節修改
- 設置部分 eslint rule 為警告,保障開發體驗,並且在 pre-commit 與 CI 中把警告視為不通過,保證嚴格的代碼規範
- 可以在 IDE (vscode),git hooks,CI 中添加規範校驗攔截
- 可以使用 husky 與 lint-staged 很方便地做關於 lint 的 git hooks
- git hooks 的規範校驗可以通過 git commit -n 跳過,需要在 CI 層繼續加強校驗
推薦前端規範文章:
《前端開發規範:命名規範、html規範、css規範、js規範》
作者:山月行 全棧成長之路
轉發鏈接:https://mp.weixin.qq.com/s/YPErjYubpM6WFrsCPcR3CQ