如何保障前端項目的代碼質量

時間 2019-11-05

標籤如何保障前端項目代碼質量简体版

原文原文鏈接

對於中大型前端項目，項目規範與代碼質量尤其重要。當功能需求變動或須要重構時，爲所欲爲的(糟糕的)代碼可能帶來比從新開發還麻煩的問題。javascript

1 前端項目代碼中的常見問題

1.1 凌亂的書寫風格，閱讀體驗差

這個問題不用做過多闡述，想必接手過他人代碼的同窗，多少都有些體會。簡單來講，太過隨意的代碼會讓強迫症患者難以容忍，難以閱讀理解的代碼有時甚至不如推倒重來。css

1.2 低質量的編碼，bug 不斷

什麼樣的代碼是低質量或高質量的？好的代碼可能會讓你如讀小說通常被吸引，糟糕的代碼會讓你看一眼就不想繼續、甚至看半天而不知所云。html

有人可能認爲初級程序員纔會有這種問題，其實否則，一些工做經驗兩三年的同窗寫的代碼依然如此。對於一些我的自學意識不夠積極、沒有團隊規範性指引的同窗，很容易習慣成「學習半年、而後重複三年無長進」的狀況。前端

拿出來你可能不太願意相信，下面這些例子即來源於真實項目。你能儘量地找出其中存在的各類問題嗎？vue

圖1java

圖2node

圖3git

圖4程序員

圖5es6

圖6

圖7

以上只是截取的一些很簡短的列子，那麼涉及大塊複雜邏輯的地方會是怎樣的，試試發揮一下你的想象力。

1.3 功能不分離，邏輯糅合，難以閱讀和理解

這種問題實際上是很是廣泛的。一個函數幾百行、一個文件數千行、一個類幾十個方法、方法參數定義隨意、沒有任何註釋、方法與變量命名無明確的語義、數據修改與變動穿插在各類方法中等等。這樣的編碼方式，你要去理解它的邏輯每每真的很難，通常只能一塊塊一行行的去作閱讀理解（可能還會開啓邊看邊罵娘模式）。

這主要緣由在於開發者我的的基礎知識能力、編碼經驗和意識等的不足。

其實針對這種狀況，常見的開源的編碼規範都會有所說起。個人建議是這些同窗應該好好溫習一下面向對象編程、函數式編程、數據結構、常見設計模式，看一看各類開源的編碼規範並嘗試去真正的理解它們。當你回顧一個月前的代碼時，發現能夠改進或重構使得編碼邏輯更爲簡潔清晰，說明你是在成長與進步的。

常常看到各類社區中都會有同窗問這類問題：新項目正在選型，Vue.js、React、Angular 三大框架哪一個合適？其實團隊開發成員對這些都比較有經驗，哪一種均可以；若是團隊成員前端開發經驗大都不是太豐富或人員不夠穩定，選擇 Vue.js 最適合，爲何？由於它更簡單簡潔，容易上手。Vue.js 經過 prop、data、computed、method、watch 等各類鉤子，必定程度上限定了編碼方式與風格，使得初級開發者寫出來的代碼也不會太難看，這也是它愈來愈受社區推崇的緣由之一。

2 保障前端項目編碼質量的方法

如何保障前端項目的編碼質量呢？依我看來能夠從這幾個角度考慮：制定編碼規範、開發工做流 lint 風格強制檢查、按期 Code Review、單元測試。

2.1 制定項目編碼規範

團隊協做項目中，編碼規範尤其重要。對於初級程序員，因經驗欠缺，編碼規範的要求能夠避免許多低級問題的產生；對於多人團隊來講，風格一致的編碼約定，在協做開發、代碼移交等時，能夠在很大程度上下降風險和成本。

那麼編碼規範應當如何制定？

沒有最好的風格，只有團隊認同的一致性約定。通常來講能夠由團隊負責人牽頭制定，成員提意見補充，最後落地成團隊規範並嚴格執行。業界有不少優秀前端團隊開源的規範可供參考。如：

參考 Angular 編碼風格指南 | 中文
參考 Airbnb JavaScript Style Guide | 中文參考
參考 Code Guide by @imweb
參考 fex-team/styleguide
參考 es6-code-style-guide
參考 idiomatic.js - 書寫具有一致風格、通俗易懂 JavaScript 的原則
參考 JSDoc 中文文檔
參考 es6 編程風格
參考 Vue.js 風格指南
參考 Vue.js 組件編碼規範

學習編碼規範約定是有必要的，但你能在看完後並真正的理解它們嗎？

2.2 在開發工做流中配置 lint 風格檢查與修正

在開發工做流中引入工具輔助，能夠強制性地實現編碼書寫和提交過程當中的 lint 校驗。能夠怎麼作？條條大道通羅馬，下面以當前流行的 Git Hook 方案舉例供參考。

2.2.1 開發編輯器及 lint 工具配置

咱們在項目中配置 TSLint 插件以校驗 typeScript；配置 styleLint 插件以校驗 CSS/LESS。

咱們約定團隊開發均採用 vscode 編輯器，並至少安裝如下插件輔助開發：

TSLint
stylelint
Document This
EditorConfig for VS Code
Prettier - Code formatter
Debugger for Chrome

2.2.2 添加 .editorconfig 文件

因爲不一樣開發者可能使用的編輯器不一樣，但各類編輯器基本都支持 .editorconfig，故每一個項目都應當包含 .editorconfig，用來統一配置編輯器的換行、縮進存儲格式。

配置參考：

# http://editorconfig.org
root = true

[*]
indent_style = space                    # 輸入的 tab 都用空格代替
indent_size = 2                         # 一個 tab 用 2 個空格代替
# end_of_line = lf # 換行符使用 unix 的換行符 \n
charset = utf-8                         # 字符編碼 utf-8
trim_trailing_whitespace = true         # 去掉每行末尾的空格
insert_final_newline = true             # 每一個文件末尾都加一個空行

[*.md]
trim_trailing_whitespace = false        # .md 文件不去掉每行末尾的空格
複製代碼

2.2.3 配置 Git Hook 強制執行編碼風格檢測與修正

藉助 Git Hook，能夠在提交代碼時執行風格檢測與修正，當存在沒法經過的內容時，提交會被 block，從而實現編碼規範的強制性執行。

能夠利用如下幾個工具來實現這個流程：

husky 它會安裝一系列 git hook 到項目的 .git/hook 目錄中，這些鉤子能夠檢測 package.json 中的 scripts 腳本命令配置，並在代碼提交時執行它（咱們這裏利用 pre-commit 鉤子）
lint-staged 能夠取得全部被提交的文件並依次執行配置好的任務命令
styleLint/TSLint/ESlint 各類 lint 校驗工具，能夠配置到 lint-staged 的任務中
prettier 配置到 lint-staged 的任務中，能夠實現修正可自動格式化的編碼風格

package.json 中的相關配置信息參考：

{
  "scripts": {
    "precommit": "lint-staged",
  },
  "lint-staged": {
    "*.ts": [
      "tslint --fix",
      "prettier --parser typescript --single-quote --print-width 120 --write",
      "git add"
    ],
    "*.less": [
      "stylelint --fix",
      "prettier --parser less --print-width 120 --write",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^0.14.3",
    "prettier": "^1.13.5",
    "prettier-stylelint": "^0.4.2",
    "stylelint-config-standard": "^18.2.0",
    "stylelint": "^9.4.0",
    "stylelint-config-prettier": "^4.0.0"
  }
}
複製代碼

.prettierrc 配置文件參考：

{
  "singleQuote": true,
  "trailingComma": "es5",
  "printWidth": 120,
  "overrides": [
    {
      "files": ".prettierrc",
      "options": { "parser": "json" }
    }
  ]
}
複製代碼

.stylelintrc 配置配置參考：

{
  "extends": [
    "stylelint-config-prettier",
    "stylelint-config-standard",
    "./node_modules/prettier-stylelint/config.js"
  ],
  "rules": {
    // 定義一些適合團隊約定的規則
  }
}
複製代碼

經過以上配置，當代碼提交時，會在 pre-commit 階段執行 .git/hook/precommit 鉤子，該鉤子會查找並執行 scrpits 中的 precommit 命令，因而 lint-staged 定義的任務會被逐個執行。這套方案也是當前比較流行的作法，在不少開源項目中都有所應用。

拓展閱讀：

2.3 執行 Code Review

編碼規範與 lint 檢查只能讓你們的編碼風格保持一致性，卻沒法避免低質量輸出的問題。而這種問題對團隊和產品來講每每倒是致命的。

低質量的代碼不只僅只是會製造各類低級 bug，讓測試同窗測到沒脾氣，對產品來講，可能很小的需求改動卻須要代碼有巨大的變更，致使產品迭代週期被潛在地延長。另外，當你們的精力老是聚焦於需求開發和 bug 修復時，產品設計的細節就顧不了那麼多了（別跟我說什麼精益求精，趕時間解決完 bug 就燒香拜佛了），這對產品體驗來講也是很要命的。

什麼樣的代碼是好的，什麼樣的代碼是很差的？這來源於知識的學習運用和開發經驗的日積月累。低質量的編碼說到底仍是經驗不一樣、水平存在差別。對於我的來講要經過不斷的學習積累自我提高，對於團隊來講進行 Code Review 評審是有必要的。

那麼 Code Review 應當如何進行？

Code Review 的形式能夠多種多樣。如 GitHub 上許多流行項目採用 PR(Pull Request) 工做流的方式，一個 PR 至少通過三人次 review 經過才能合入，這能從流程上較好地保障項目代碼質量。在有的開發團隊或企業，會引入 gerrit 這種代碼審覈平臺，過程與此大體類似。但對許多快速迭代的業務產品開發團隊來講，這種須要多人評審經過的模式都不太適合：人力有限、時間緊迫、顧不了那麼多了，因而即便 gerrit 也流於形式，編碼質量只能落到開發人員我的的肩膀上。

相比較而言，按期進行小組討論形式，問題的提出能夠獲得快速反饋和總結，這會讓你們更有動力一些。

通常來講團隊內有新人入職，基本的 Code Review 是有必要的，這時候編碼規範與風格是 review 的重點。當你們對常見的基本問題都有了比較一致且明確的認識後，探討交流學習則會逐漸成爲 Code Review 的主要內容。

對於內部交流氛圍濃厚的團隊，能夠鼓勵成員之間互相審閱提交的編碼。對大多數團隊來講，能夠這麼來作：主要負責人以抽查瀏覽的形式快速審閱成員提交的代碼，發現有問題的地方提出並打回改進（問題較多的同窗的代碼應重點關注）；團隊按期(能夠是每週)以例會討論的形式，對一週提交的代碼進行抽樣和總結式評審，學習好的編碼方式、探討很差的編碼的理由，甚至進而沉澱出適合團隊的編碼約定。

另外注意一點，Review 過程的操做方式和表達用語很是重要，應當是輕鬆的溝通交流學習的方式，不要把 Code Review 執行成了批判會。

拓展閱讀：

2.4 編寫單元測試

前端項目寫單元測試，對不少人來講是不肯意的，由於編寫過程太過複雜。但基本的單元測試是能夠寫的，公共方法和組件的修改可能會爲某些調用模塊製造潛在的 BUG，良好的單元測試能夠在出現問題時快速反饋出來。

咱們當前對項目單元測試的基本要求是這樣的：

公共方法、服務類必須寫單元測試
公共組件應當書寫單元測試，應儘量覆蓋到各類功能點
業務組件能夠書寫簡單的測試
注意測試代碼質量，應當反覆經過測試覆蓋率評估和改進測試代碼

Vue.js/React/Angular 三大框架都有完善的單元測試實現體系，在項目中引入單元測試的成本並不高，高的是測試代碼編寫的過程。在某些狀況下我認爲這種「高成本」是值得的。另外需注意，單元測試的執行必定要與 CI 集成，才能真正發揮它實時性反饋問題的做用。

2.5 其餘

2.5.1 使用靜態檢查語言 TypeScript / Flow

JavaScript 是一種語法簡單使用靈活的弱數據類型語言，而正是這種過於靈活的特性，使得開發者可以任性地書寫，但任性是須要成本和代價的。

有時會看到一些後端同窗會說，前端看上去也沒那麼難嘛，我只學了一天就開始上手擼代碼了。他們或許說的沒錯，可是有經驗的前端同窗去看一下他們此時產出的代碼，每每都會表示不忍直視。許多前端開發的同窗並不是計算機相關專業出身，沒有太多相關的基礎理論知識做爲背景，剛開始幹活時在代碼輸出上「爲所欲爲任意妄爲」的狀況更爲廣泛。

TypeScript 和 Flow 近兩年來愈來愈火熱，幾乎當前流行的前端開源產品都在轉向使用它們，這足以體現它們存在的重要價值。靜態檢查語言在編碼階段便可檢測並提示出潛在的類型引用風險，能夠在很大程度上避免許多因粗心、誤用帶來的邏輯 bug。良好的類型定義會使得項目模塊邏輯結構更爲清晰可控。藉助編輯器強大的類型提示功能，代碼編寫甚至無需看詳細文檔便可快速瞭解用法。特別是中大型的複雜項目，選用它們絕對是利大於弊。