如何保證前端項目代碼質量

What

什麼是代碼自己的質量?

代碼自己的質量: 包括複雜度, 重複率, 代碼風格等。

• 複雜度: 項目代碼量，模塊大小，耦合度等
• 重複率: 重複出現的代碼區塊佔比，一般要求在5%如下(藉助平臺化工具如Sonar)
• 代碼風格: 代碼風格是否統一(動態語言代碼如JS, Python風格不受約束)

代碼質量降低惡性循環

常見的代碼質量降低的緣由:

• 破罐破摔: 在爛代碼上迭代代碼罪惡感比較小
• 傳染性: 不在乎代碼質量, 只關注業務的產出
• 愛莫能助

常見的致使惡性循環的場景:

• 業務壓力太大

爛代碼產生的常見緣由是業務壓力大，致使沒有時間或意願講究代碼質量。由於向業務壓力妥協而生產爛代碼以後，開發效率會隨之降低，進而致使業務壓力更大，造成一種典型的惡性循環。

• 經過增長人力解決業務壓力

爲了應對業務壓力，常見的作法就是向項目中增長人力，可是單純地增長人力的話，會由於風格不一致、溝通成本上升等緣由致使爛代碼更多。

那麼咱們應該如何解決呢?

這是一個長期堅持的過程。

代碼質量管控四個階段

• 規範化

創建代碼規範與Code Review制度

1. airbnb
2. standard
3. node-style-guide
4. google javascript style guide
5. google html/css style guide
6. Vue風格指南

我以爲統一項目目錄結構也是規範化的一種(好比咱們用腳手架建立項目模板), 一個規範化的目錄結構大大下降新人的上手成本。

• 自動化

使用工具(linters)自動檢查代碼質量。

• 流程化

將代碼質量檢查與代碼流動過程綁定。

質量檢查與代碼流動綁定後的效果：

備註:

1. 編輯時候: 經過編輯器插件, 實時查看質量檢查

2. 能夠利用CI(Jekins/Travis)把構建發佈過程搬到線上, 先跑代碼掃描, 測試代碼等, 而後沒有錯誤再進行build, build成功經過ssh推到服務器。
複製代碼

• 中心化

以團隊總體爲視角，集中管理代碼規範，並實現質量情況透明化。

當團隊規模愈來愈大，項目愈來愈多時，代碼質量管控就會面臨如下問題：

1. 不一樣項目使用的代碼規範不同

2. 部分項目因爲放鬆要求，沒有接入質量檢查，或者存在大量未修復的缺陷

3. 沒法從團隊總體層面上體現各個項目的質量情況對比

爲了應對以上問題，須要建設中心化的代碼質量管控體系，要點包括：

代碼規範統一管理。經過腳手架命令垂直管理代碼掃描配置規則集, 自動安裝，不在本地寫規則。一個團隊、一類項目、一套規則。

---

• [待定] 使用統一的持續集成服務(Jekins/Travis等)。質量檢查不經過的項目不能上線。

• [待定] 創建代碼質量評分制度(藉助Sonar)。讓項目與項目之間可以橫向對比，項目自身可以縱向對比，而且進行彙總反饋。

Why

代碼質量是團隊技術水平和管理水平的直接體現。

看代碼的時間遠遠多於寫代碼的時間

目前前端項目出現的問題

• 書寫風格不統一, 閱讀體驗差
• 維護性差, 複用性差(Code Review互相進步)
• 容易出現低質量代碼, 代碼返工率高
• git commit不規範

How

經過哪些手段來保證代碼質量?

EditorConfig

EditorConfig在多人協做開發項目時候, 支持跨編輯器, IDE來支持維護一致的編碼樣式(文件格式)。

VSCode插件EditorConfig for VS Code提供一鍵生成.editorconfig。

查看實例。

TypeScript

• 官網介紹。
• 中文awesome-typescript
• TypeScript體系調研報告
• 2018年度JS趨勢報告

Git Hooks

Git能在特定的重要動做發生時觸發自定義腳本。 有兩組這樣的鉤子：客戶端的和服務器端的。 客戶端鉤子由諸如提交和合並這樣的操做所調用，而服務器端鉤子做用於諸如接收被推送的提交這樣的聯網操做, 咱們目前使用的大多數是客戶端鉤子。

經過husky集成git hooks, 若是對git想有更全面的理解推薦閱讀GIt文檔。

husky會安裝一系列的git hook到項目的.git/hook目錄中。

下面兩張圖分別對比沒有安裝husky與安裝了husky的git目錄區別:

當你用 git init 初始化一個新版本庫時，Git 默認會在這個目錄中放置一些示例腳本(.sample結尾的文件)。

pre-commit

pre-commit 鉤子在鍵入提交信息前運行。 它用於檢查即將提交的快照，你能夠利用該鉤子，來檢查代碼風格是否一致（運行相似 lint 的程序。

• lint-staged: 能夠獲取全部被提交的文件並執行配置好的任務命令,各類lint校驗工具能夠配置好lint-staged任務中。
• prettier: 能夠配置到lint-staged中, 實現自動格式化編碼風格。
• stylelint
• eslint
• tslint
• eslint-plugin-vue: Vue.js官方推薦的lint工具

關於爲何選擇prettier, 以及eslint 與prettier區別?。

關於prettier配置。 關於stylelint配置。 關於eslint配置。

commit-msg

• commitlint。

commit-msg 能夠用來在提交經過前驗證項目狀態或提交信息, 使用該鉤子來覈對提交信息是否遵循指定的模板。

關於git hooks在package.json配置:

測試

unittest

• Jest
• Mocha

e2e

• Nightwatch
• Cypress

CHANGELOG

更新日誌, standard-version。

Code Review

• [待定] Review制度,咱們目前公司在代碼merge時候多人審覈才經過。

如何快速落地到當前業務

前端腳手架(xx-cli)

採用中心化集中管理代碼掃描配置文件的思路, 把code lint配置文件作成一個npm包發到內網, 而後擴展腳手架命令一鍵執行下發遠程配置文件到本地項目, 而且把新增的package.json依賴打進來, 你們後面再安裝新的依賴便可。

所謂中心化管理: 全部項目代碼配置文件以遠程配置文件爲準, 若是你本地有同名配置會被刪除, 這樣方便後續咱們更新配置文件好比(增長vw/vh適配), 以及全部業務同步問題。

目前只有基於vue.js項目的lint腳本命令, 後續有別的項目, 考慮經過

dc-cli lint -- vue
dc-cli lint -- node
擴展
複製代碼

demo演示

demo演示如何在舊項目中植入代碼質量檢測? 因爲這部分是在內網演示就不發不出來了。

至於腳手架能夠參考我以前的demoeasy-cli。這是比較全的demo。

Future

Jekins自動化

Sonar

Github:

SonarQube 是一款領先的持續代碼質量監控平臺，開源在github 上，能夠輕鬆配置在內網服務器，實時監控代碼，幫助瞭解提高提高團隊項目代碼質量。經過插件機制，SonarQube能夠繼承不一樣的測試工具，代碼分析工具，以及持續集成工具。

與持續集成工具（例如 Hudson/Jenkins 等）不一樣，SonarQube 並非簡單地把不一樣的代碼檢查工具結果（例如 FindBugs，PMD 等）直接顯示在 Web 頁面上，而是經過不一樣的插件對這些結果進行再加工處理，經過量化的方式度量代碼質量的變化，從而能夠方便地對不一樣規模和種類的工程進行代碼質量管理。

行業內提到"代碼質量管理, 自動化質量管理", 通常指的都是經過Sonar來實現。

用Sonar可以實現什麼?

• 技術債務(sonar根據"規則"掃描出不符合規則的代碼)
• 覆蓋率(單元測試覆蓋率)
• 重複(重複的代碼, 有利於提醒封裝)
• 結構
• …

sonarjs

sonar支持多種編程語言, 其中包括JavaScript. 如sonarjs

最後打個廣告,歡迎關注個人公衆號 全棧小窩。