資訊專欄INFORMATION COLUMN
摘要：官方出品的工具列表也是個非常不錯的參考。很多同學選擇在持續集成階段后文用代稱做，比如使用遠程的來觸發。常見做法是使用或者在本地提交之前做。本文作者王仕軍，商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
Lint 是什么？具備基本工程素養的同學都會注重編碼規范，而代碼風格檢查（Code Linting，簡稱 Lint）是保障代碼規范一致性的重要手段，你的工作流中有 Lint 環節么？有的話你用的爽么？你在團隊中推廣過 Lint，但是大家都不買賬？究竟是為啥？
探討怎么做之前，我們很有必要給 Lint 來個清晰、準確的定義，wikipedia 的定義如下：
In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.
簡單來說，Lint 就是對代碼做靜態分析，并試圖找出潛在問題的工具，實戰中我們也用 Lint 來指使用工具的過程。
為什么要 Lint？使用 Lint 會有什么好處呢？在我看來至少具有如下 3 點：
更少的 Bug，劍橋大學的研究發現，全世界每年因為軟 Bug 造成的經濟損失約 3120 億美金；
更高的開發效率，工程師平均會花掉 50% 的工作時間定位和解決各種 Bug，其中不乏那些顯而易見的低級錯誤，而 Lint 很容易發現低級的、顯而易見的錯誤；
更高的可讀性，代碼可讀性的首要因子是“表面文章”，表面上看起來亂糟糟的代碼通常更難讀懂；
可以毫不客氣的說，如果你不做 Lint，就是在浪費自己的時間，浪費公司的資源。既然做 Lint 的預期效果很好？該怎么做呢？
提交后 Lint：反饋鏈條太長？說到怎么做，多數人會自然而然的想到各種 Lint 工具，目前社區中針對各種語言都開發了 Lint 工具，前端能用到的就有大把：ESLint、Standard、SCSSLint、JSONLint、HTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是個非常不錯的參考。
很多同學選擇在持續集成階段（后文用 CI 代稱）做 Lint，比如使用遠程的 Git Hooks 來觸發。但是從實際的經歷來看，這種做法的反饋鏈條通常如下：
代碼提交 --> 發現問題(遠程) --> 修復問題 --> 重新提交 --> 通過檢查(遠程)
整個過程可能會浪費掉你不少時間，畢竟 CI 過程通常不僅是在做 Lint，如果你是那種不知道自己時間每天都去哪兒了的工程師，可以反思下自己或者團隊的工作流是否是這樣。并且，請相信我，你不是少數人。
你有沒有這樣的經歷：吭哧吭哧寫了幾天代碼，各種驗收都通過了，最后被 CI 拒絕，竟是因為你的代碼中少加了一個逗號，這時候心情簡直崩潰到無法形容：
從 GitHub 上各種修復 Lint 的提交數量不難發現工程師在修復 Lint 問題上浪費的時間，比如搜索 "fix lint"，多達 45W 次提交：
再比如搜索 “fix indent”，多達 226W 次提交，是不是很觸目驚心？
只在 CI 流程做 Lint 的缺點也是顯而易見的：
Lint 在整個開發工作流中的反饋鏈條太長，浪費時間、注意力和資源，最致命的；
CI 流程搭建成本比較高，即使有各種 CI 服務，步驟也還是比較繁瑣；
我們該怎么改進？
提交前 Lint：錯誤信息不相關？為了縮短 Lint 的反饋鏈條，把 Lint 挪到本地是最有效的辦法。常見做法是使用 husky 或者 pre-commit 在本地提交之前做 Lint。
使用 husky 的具體做法如下：
首先，安裝依賴：
npm install -D husky yarn add --dev husky
然后修改 package.json，增加配置：
{
"scripts": {
"precommit": "eslint src/**/*.js"
}
}
最后嘗試 Git 提交，你就會很快收到反饋：
git commit -m "Keep calm and commit"
但是在遺留代碼倉庫上工作的同學很快會遇到新的問題，開啟 Lint 初期，你可能會面臨成千上萬的 Lint Error 需要修復。部分同學對下面這個圖可能并不陌生：只改了文件 A，但是文件 B、C、D 中也有大量錯誤。
把整個倉庫都格式化不失為一種選擇，但是實際上需要很大的勇氣。多數人在項目中運用新工具都希望是漸進式的，而不是推到重來式的，因為相比而言，業務系統穩定是更重要的事情。簡單的把 Lint 挪到本地，反饋鏈條是縮短了，但是面對每次改動，工具還是給出了太多不相關的信息，這無疑與小步快跑的互聯網節奏是相違背的。
該怎么破？
只 Lint 改動的：66666如果把 Lint 挪到本地，并且每次提交只檢查本次提交所修改的文件，上面的痛點就都解決了。Feedly 的工程師 Andrey Okonetchnikov 開發的 lint-staged 就是基于這個想法，其中 staged 是 Git 里面的概念，指待提交區，使用 git commit -a，或者先 git add 然后 git commit 的時候，你的修改代碼都會經過待提交區。
lint-staged 用法如下：
首先，安裝依賴：
npm install -D lint-staged yarn add --dev lint-staged
然后，修改 package.json 配置：
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"src/**/*.js": "eslint"
}
}
最后，嘗試提交的效果：
實際上，lint-staged 給了你提交前代碼操作的更大自由度，比如使用下面的配置，自動修復錯誤：
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"src/**/*.js": ["eslint --fix", "git add"]
}
}
或者使用下面的配置，自動格式化代碼（謹慎使用）：
{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"src/**/*.js": ["prettier --write", "git add"]
}
}
此外，lint-staged 和 prettier 已經集成到 create-react-app 中了。你是不是也應該好好打磨下自己的 Lint 工作流了？
總結有人說前端攻城獅是世界上最奇怪的動物，提交代碼時用 prettier 把代碼排版的很美觀，但部署上線時又使用 uglify 把代碼壓縮的連親媽都不認了，事實是，如果我們寫出來的代碼本來就很丑陋，就根本不需要用 uglify。希望讀到這里的你能把 Lint 工作流打磨到極致，把更多時間專注在解決真正的問題上，成為真正高效的工程師。
One More Thing本文作者王仕軍，商業轉載請聯系作者獲得授權，非商業轉載請注明出處。如果你覺得本文對你有幫助，請點贊！如果對文中的內容有任何疑問，歡迎留言討論。想知道我接下來會寫些什么？歡迎訂閱我的掘金專欄或知乎專欄：《前端周刊：讓你在前端領域跟上時代的腳步》。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/11792.html
摘要：如果編輯器在編碼時實時給出反饋，對開發者個人而言才是最高效的，在提交時做強制檢查只是從團隊的視角保證編碼風格的規范性和一致性。 工欲善其事必先利其器，軟件工程師每天打交道最多的可能就是編輯器了。入行幾年來，先后折騰過的編輯器有 EditPlus、UltraEdit、Visual Studio、EClipse、WebStorm、Vim、SublimeText、Atom、VSCode，現在...
摘要：如果編輯器在編碼時實時給出反饋，對開發者個人而言才是最高效的，在提交時做強制檢查只是從團隊的視角保證編碼風格的規范性和一致性。 工欲善其事必先利其器，軟件工程師每天打交道最多的可能就是編輯器了。入行幾年來，先后折騰過的編輯器有 EditPlus、UltraEdit、Visual Studio、EClipse、WebStorm、Vim、SublimeText、Atom、VSCode，現在...
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
摘要：對于項目的編碼規范而言，主要有兩種選擇和。此外由于性能問題，官方決定全面采用，甚至把倉庫作為測試平臺，而的解析器也成為獨立項目，專注解決雙方兼容性問題。最近在我的項目的編碼規范中全量的用代替了針對其中遇到的問題做一個記錄。 ??對于Typescript項目的編碼規范而言，主要有兩種選擇ESLint和TSLint。ESLint不僅能規范js代碼，通過配置解析器，也能規范TS代碼。此外由...
閱讀 4171·2021-09-22 15:34
閱讀 2781·2021-09-22 15:29
閱讀 503·2019-08-29 13:52
閱讀 3362·2019-08-29 11:30
閱讀 2273·2019-08-26 10:40
閱讀 846·2019-08-26 10:19
閱讀 2267·2019-08-23 18:16
閱讀 2327·2019-08-23 17:50
