如何提升團隊代碼質量

時間 2019-11-17

標籤如何提升團隊代碼質量简体版

原文原文鏈接

前言

爲何開發都喜歡重構代碼，而不是在原有的代碼上作持續迭代呢？我想，糟糕的代碼質量，是你拒絕在源代碼上繼續修改的重要理由，甚至沒有之一。所以，統一團隊代碼風格，提升團隊代碼質量，是頗有必要的一件事。下面是我在團隊代碼質量管理上的一些經驗分享。javascript

約定代碼風格

一個團隊必定要有統一的代碼風格，而且一以貫之，使開發人員在跨模塊甚至跨應用開發時，能夠無痛切換。這裏推薦騰訊團隊的代碼規範，從命名到HTML、CSS、Javascript的書寫規範，包羅萬象，並輔以代碼說明，淺顯易懂。也能夠根據自身團隊的狀況作一些調整，不必定全盤複用。不足之處就是兩年多沒有任何更新了，一些ES6\7\8的規範有所欠缺。前端

另外，若是你的項目是基於vuejs開發的，你可能還要遵循一個vue的開發規範，使用官網的風格指南便可。vue

啓用ESLint

約定了代碼風格，如何保證執行呢？靠肉眼一行一行去看確定是不行的，那麼大名鼎鼎的ESLint你確定是聽過的。ESLint是須要配置的，具體怎麼配置能夠去官網本身查，這裏推薦使用standard風格，固然你能夠選擇airbnb或者徹底手動配置，根據自身團隊狀況來就好。java

當第一次接觸ESLint時，大部分人都是痛苦的，寫一段代碼滿屏飄紅，不少人適應不了就把它關了。其實只要你適應它幾天，就能寫出徹底符合ESLint要求的代碼了，並且還能夠配置vscode的ESLint插件，配置保存時自動格式化，哪怕寫錯也能幫你自動改正，減小適應的痛苦。react

它的優勢就是統一團隊代碼風格，矯正代碼書寫規範，配合編輯器的保存自動格式化，效果更佳。git

除了ESLint，還有CSSLint、HTMLHint，顧名思義，分別是統一CSS和HTML風格的，也能夠一塊兒用起來。github

使用githook校驗提交的代碼

即使是啓用了ESLint，仍是有人將不符合規範的代碼push到了倉庫中，這種問題又要怎樣去規避呢？框架

利用git的hook函數，在commit以前去執行eslint或其餘命令，校驗提交的代碼是否符合規範。若是不符合規範，就會輸出報錯信息，阻止這一次的提交。編輯器

通常前端項目可使用husky插件配置githook，而後使用lint-staged限制只對暫存區的代碼作掃描，否則會對整個git倉庫作掃描，一來耗時，二來可能會掃出大量問題，必須所有修復才能提交。ide

使用QA工具掃描項目

以上主要是對代碼風格的規範和約束，若是想對代碼作進步一的質量優化，還要藉助更高級的QA工具，好比公司的java開發常用的findBugs，sonar qube 等。

其中sonar很強大，支持25中開發語言，其中也包括JavaScript、HTML和CSS。但若是要配置在vscode中使用時，須要依賴本地的java環境，配置起來可能會有些麻煩。不過其官網的文檔很詳細，徹底能夠當作代碼指南來參考。

除了sonar，還有個工具DeepScan，除了能掃描js，還支持vue和react語法，能幫助你發現不符合js框架規範的bug。最棒的是，他有可視化的儀表盤，能夠直觀的分析代碼質量，而且支持團隊管理。不過它只能同步github上的項目，目前用下來，還會有偶爾同步失敗的問題。我是將gitlab上的項目拷貝一份到github，再用DeepScan同步過來掃描。它有免費版本和收費版本，收費版本能夠同步github上的private項目，不過我在試用狀態下，是不能正常同步private項目的，不知道是bug仍是設定如此。

結對 code review

咱們都但願工具能幫咱們解決全部問題，但現實每每沒有那麼美好。縱然上面的工具已經作得很棒了，但它也僅僅是幫咱們統一了代碼風格，避免了一些瑣碎且基礎的錯誤。好的代碼必定是沒有錯誤的代碼，但沒有錯誤的代碼不必定是好代碼，上述工具作好了前一半，後一半仍是須要人來參與。

結對 code review的優勢：

每一個人的技能樹都不盡相同，各自擅長的東西也不同，多一我的來review，天然會有更大的概率發現問題；
不只能相互發現問題，也能相互學習對方好的設計思想和代碼習慣，取其精華，去其糟粕。建議每次結對都換一我的，這樣收益更多；
相對於工具，人能夠從更宏觀的角度想問題，能夠結合需求、使用場景、邊界值等因素來分析代碼，而不是隻看一個點寫的好很差。

結語

全部能落實的方案，纔有意義，不然即是空談。在代碼質量的提升上，不建議一蹴而就，否則會有很大的推行阻力。所以，咱們能夠按部就班，讓團隊慢慢去適應。好比能夠先約定代碼風格，在開發新項目或重構項目時，再啓用ESLint，等團隊適應了，再執行QA工具掃描、結對 code review等。