為什么大廠前端寫代碼更快、更穩、更省心？看完這個我才懂......
Hello，大家好，我是 Sunday。
對于一些大型的企業級項目而言，通常情況下我們都是需要一個團隊來進行開發的。而又因為團隊人員對技術理解上的參差不齊，所以就會導致出現一種情況，那就是一個項目無法具備統一的編程規范，導致項目的代碼像多個不同材質的補丁拼接起來一樣
所以，我們就需要通過一些方式來規劃 統一變成標準，那么這種統一的方案就叫做 標準化！
整個標準化包含很多的內容，今天咱們先說兩個主要部分：
- 編碼規范
- git 規范
編碼規范
1.使用 ESLint 進行代碼格式檢查
ESLint 是 2013年6月 創建的一個開源項目，它的目標非常簡單，只有一個，那就是 提供一個插件化的 javascript 代碼檢測工具 ，說白了就是做 代碼格式檢測使用的
多數前端項目中，都會包含一個 .eslintrc.js 文件，這個文件就是 eslint 的配置文件。
圖片
// ESLint 配置文件遵循 commonJS 的導出規則，所導出的對象就是 ESLint 的配置對象
// 文檔：https://eslint.bootcss.com/docs/user-guide/configuring
module.exports = {
// 表示當前目錄即為根目錄，ESLint 規則將被限制到該目錄下
root: true,
// env 表示啟用 ESLint 檢測的環境
env: {
// 在 node 環境下啟動 ESLint 檢測
node: true
},
// ESLint 中基礎配置需要繼承的配置
extends: ["plugin:vue/vue3-essential", "@vue/standard"],
// 解析器
parserOptions: {
parser: "babel-eslint"
},
// 需要修改的啟用規則及其各自的錯誤級別
/**
* 錯誤級別分為三種：
* "off" 或 0 - 關閉規則
* "warn" 或 1 - 開啟規則，使用警告級別的錯誤：warn (不會導致程序退出)
* "error" 或 2 - 開啟規則，使用錯誤級別的錯誤：error (當被觸發的時候，程序會退出)
*/
rules: {
"no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
"no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off"
}
};基于 ESLint 如果我們出現不符合規范的代碼格式時，那么就會得到一個對應的錯誤。
圖片
這個錯誤表示：
- 此時我們觸發了一個 《錯誤級別的錯誤》
- 觸發該錯誤的位置是 在 Home.vue 的第 13 行 第九列 中
- 錯誤描述為：字符串必須使用單引號
- 錯誤規則為：quotes
那么想要解決這個錯誤，通常情況下我們有兩種方式：
- 按照 ESLint 的要求修改代碼：在 Home.vue 的第 13 行中把雙引號改為單引號
- 修改 ESLint 的驗證規則：在 .eslintrc.js 文件中，新增一條驗證規則
"quotes": "error" // 默認
"quotes": "warn" // 修改為警告
"quotes": "off" // 修改不校驗2.使用 prettier 完成自動格式化
圖片
prettier 是一個可以在保存時自動格式化代碼的工具
- 在 VSCode 中安裝 prettier 插件（搜索 prettier），這個插件可以幫助我們在配置 prettier 的時候獲得提示
圖片
- 在項目中新建 .prettierrc 文件，該文件為 perttier 默認配置文件（復制后把注釋去掉）
{
// 不尾隨分號
"semi": false,
// 使用單引號
"singleQuote": true,
// 多行逗號分割的語法中，最后一行不加逗號
"trailingComma": "none"
}- 打開 VSCode 《設置面板》
- 在設置中，搜索 save ，勾選 Format On Save
圖片
- 在任意代碼 js 文件中，右鍵選擇 默認格式化工具，指定為 prettier
圖片
圖片
在之后我們寫代碼的過程中，只需要保存代碼，那么 perttier 就會幫助我們自動格式化代碼，使其符合 ESLint 的校驗規則。而無需我們手動進行更改了。
git 規范
1.什么是約定式提交規范
在前面我們通過 prettier + ESLint 解決了代碼格式的問題。但是除了 代碼格式規范 之外，還有另外一個很重要的規范就是 git 提交規范！
當我們執行 git commit -m "描述信息" 的時候，必須添加一個描述信息。
但是很多人的描述 “天馬行空” ，這樣就會導致別人在看你的提交記錄時，看不懂你說的什么意思？不知道你當前的這次提交到底做了什么事情？會不會存在潛在的風險？
比如說，我們來看這幾條提交記錄：
圖片
你能夠想象得到它們經歷了什么嗎？所以 git 提交規范 勢在必行。
對于 git 提交規范 來說，不同的團隊可能會有不同的標準，那么咱們今天就以目前使用較多的 Angular團隊規范 延伸出的 Conventional Commits specification（約定式提交） 為例
圖片
約定式提交規范要求如下：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
-------- 翻譯 -------------
<類型>[可選 范圍]: <描述>
[可選 正文]
[可選 腳注]其中 <type> 類型，必須是一個可選的值，比如：
- 新功能：feat
- 修復：fix
- 文檔變更：docs
- ....
也就是說，如果要按照 約定式提交規范 來去做的化，那么你的一次提交描述應該式這個樣子的：
圖片
但是，這樣的描述過于復雜了。如果每次都手寫就會很麻煩。所以，我們就需要一些工具來解決這個問題。
2.Commitizen助你規范化提交代碼
Commitizen 是一個工具和標準，用于幫助開發者編寫規范化的 Git 提交消息
圖片
那么它的配置也非常簡單：
- 全局安裝Commitizen
npm install -g commitizen@4.2.4- 安裝并配置 cz-customizable 插件
npm i cz-customizable@6.3.0 --save-dev添加以下配置到 package.json 中
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}- 項目根目錄下創建 .cz-config.js 自定義提示文件
module.exports = {
// 可選類型
types: [
{ value: 'feat', name: 'feat: 新功能' },
{ value: 'fix', name: 'fix: 修復' },
{ value: 'docs', name: 'docs: 文檔變更' },
{ value: 'style', name: 'style: 代碼格式(不影響代碼運行的變動)' },
{
value: 'refactor',
name: 'refactor: 重構(既不是增加feature，也不是修復bug)'
},
{ value: 'perf', name: 'perf: 性能優化' },
{ value: 'test', name: 'test: 增加測試' },
{ value: 'chore', name: 'chore: 構建過程或輔助工具的變動' },
{ value: 'revert', name: 'revert: 回退' },
{ value: 'build', name: 'build: 打包' }
],
// 消息步驟
messages: {
type: '請選擇提交類型:',
customScope: '請輸入修改范圍(可選):',
subject: '請簡要描述提交(必填):',
body: '請輸入詳細描述(可選):',
footer: '請輸入要關閉的issue(可選):',
confirmCommit: '確認使用以上信息提交？(y/n/e/h)'
},
// 跳過問題
skipQuestions: ['body', 'footer'],
// subject文字長度默認是72
subjectLimit: 72
}- 使用 git cz 代替 git commit
圖片
那么至此，我們就完成了 git 規范 的提交配置。
