簡介：? **越高級別的程序員往往越看重代碼質量。** 本篇文章主要聊一下在團隊開發過程中，如何做到代碼質量的管控與提升。首先需要有一套規范，定義什么是好的代碼，再通過一些工具，幫助我們在實踐規范的過程中，更好地遵循規范。 > TLDR:

越高級別的程序員往往越看重代碼質量。

本篇文章主要聊一下在團隊開發過程中，如何做到代碼質量的管控與提升。首先需要有一套規范，定義什么是好的代碼，再通過一些工具，幫助我們在實踐規范的過程中，更好地遵循規范。

TLDR: 直接看第 4 點，?Iceworks Doctor?解決方案。

為何需要提高代碼質量？

好的代碼一定是整潔的，并且能夠幫助閱讀的人快速理解和定位。好的代碼可以加快應用的開發迭代速度，不必花過多的時間來修復 bug 和完善代碼。好的代碼不但能夠使得新的項目成員更容易加入項目，同時方便項目組成員快速做好 Back up。好的代碼便于促進團隊間交流合作提升開發效率。

有編碼經驗的人對代碼都有一定的“鑒賞力”，能夠憑感覺給出代碼好壞的主觀評價。但是這種憑感覺的方式太過個性隨意，所謂仁者見仁智者見智，很難達成共識，那有沒有一種公認的標準來鑒定代碼質量呢？

代碼質量評價標準

答案是有的。這里簡單分享當下較常用的評價標準，其中包括：編碼規范、可讀性、可維護性、重復度及可測試性。

編碼規范
主要包含是否遵守了最佳實踐和團隊編碼規范，是否包含可能出問題的代碼，以及可能存在安全的漏洞。編碼規范有助于提高團隊內協助的效率以及代碼的可維護性。

可讀性
Code Review 是一個很好的測驗代碼可讀性的手段。如果你的同事可以輕松地讀懂你寫的代碼，那說明你的代碼可讀性很好；反之則說明你的代碼可讀性有待提高了。遵守編碼規范也能讓我們寫出可讀性更好的代碼。

可維護性
代碼的可維護性是由很多因素協同作用的結果。代碼的可讀性好、簡潔、可擴展性好，就會使得代碼易維護；更細化地講，如果代碼分層清晰、模塊化好、高內聚低耦合、遵從基于接口而非實現編程的設計原則等等，那就可能意味著代碼易維護。除此之外，代碼的易維護性還跟項目代碼量的多少、業務的復雜程度、利用到的技術的復雜程度、文檔是否全面等諸多因素有關。

重復度
遵守 Don’t Repeat Yourself 原則，盡量減少重復代碼的編寫，復用已有的代碼。對項目定期進行代碼重復度檢測是一個很有意義的事，可以幫助開發人員發現冗余代碼，進行代碼抽象和重構。重復的代碼一旦出錯，意味著加倍的工作量和持續的不可控。如果代碼中有大量的重復代碼，就要考慮將重復的代碼提取出來，封裝成公共的方法或者組件。

可測試性
代碼可測試性的好壞，同樣可以反應代碼質量的好壞。代碼的可測試性差，比較難寫單元測試，那基本上就能說明代碼設計得有問題。

除此之外還有很多代碼質量評價標準。我們需要一些取舍，選取部分大家有共識的規則定義團隊好的代碼標準。

代碼質量建設怎么開始

當團隊有了統一的代碼質量評價標準后，便需要嚴格的執行代碼編寫規范。

工欲善其事，必先利其器

我們可以通過?SonarQube?等靜態代碼檢測工具來進行代碼質量建設。但在代碼完成發布后如果線上沒有問題的話，相信很少有人會主動優化代碼，即使有掃描結果也很難推動代碼質量的提升。

所以這里很需要平臺、工具或者工作流上的配合。否則在具體寫代碼的過程中，很容易由于開發人員的不重視，導致整個 Code Base 變得越來越差。所以提高團隊對代碼規范的認同及嚴格執行是代碼質量建設的關鍵。

當然我們也可以在代碼提交的時候，利用鉤子來控制允許提交或者拒絕提交，比如 git 的 pre-commit 和 commit-msg。但是這些都是比較滯后的方式，我們能不能更提前發現問題讓開發在功能開發過程中就把發現的問題改掉？

Iceworks Doctor

為實現 JavaScript 代碼規范的統一，并提升和改善團隊代碼質量，我們當前發布了?Iceworks Doctor?0.1.0 版本。該方案目前包括多場景統一的 ESLint 規則配置、多維度的代碼衡量標準、執行分析掃描代碼及代碼修復等模塊。通過各個模塊協調配合，評估質量評分并修復規范問題，在降低維護成本、提升執行效率的同時保障代碼規范的統一。

質量評分

當前版本通過?@iceworks/doctor?從 5 個維度對代碼進行評分：

最佳實踐：?通過?@iceworks/eslint-plugin-best-practices?分析項目，提出符合當前工程特征（對?ice?和?Rax項目友好）的最佳實踐及阻塞問題發布卡口，幫助開發者優化項目性能，避免潛在 bug 。

安全實踐：?通過?@iceworks/eslint-plugin-security-practices?掃碼代碼檢測工程中可能存在的安全風險，包含 url 、敏感成詞、明文賬密信息及 npm 包證書檢測，降低項目安全風險，守衛項目安全。

阿里代碼規范：?這一維度主要反饋開發人員對于?eslint-config-ali?阿里開發規約的遵守程度。

可維護度：?通過?typhonjs-escomplex?對文件進行掃碼，得出每個文件的可維護度，可讀性及復雜度評分。針對得分較差的文件可以進行深度分析幫助開發者更好的重構復雜代碼。

重復度：?通過?jscpd?計算重復出現的代碼區塊占比，計算出 clone 分數。并逐一列舉重復的代碼，方便開發者快速定位重復代碼，將其封裝成公共的方法或者組件。

根據上述 5 個維度通過加權平均的方式計算項目質量分，并根據木桶效應，在計算得分的過程中加大了最低分的權重，得出最終項目質量評分。

快來使用?Iceworks Doctor?測測自己項目的得分，比比誰的分數高吧~

問題修復

利用 VS Code 代碼提示能力，我們在源碼中標記出了問題代碼，輔助開發者快速定位及修復代碼。有問題的代碼會在代碼及文件名上有紅色 / 黃色波浪線標示，鼠標 hover 時可預覽問題詳情窗口，也可通過 VS Code Problems 欄查看 Errors 列表。方便開發者在更前置的開發過程中發現和修復問題。

點擊 “一鍵修復” 按鈕可快速修正問題代碼。同時在保存代碼時，實時檢測是否存在有安全風險的代碼。

您的數據是私有的：?Iceworks Doctor 是開源的，你可以很容易地看到我們收集了什么數據。我們永遠不會與任何人共享您的個人數據。

前進方向思考

愿景：?讓團隊沒有不及格（低于60分）的代碼。

整體方案的設計如下圖所示：

在后續的版本迭代中，Iceworks Doctor 將構建一個完整的系統性方案。僅需安裝一個 VS Code 插件，便可擁有從配置開發環境，輔助開發、診斷和修復質量問題到 PR 發布一整套更加便捷智能的工作流程。通過極低的成本便可維護團隊代碼質量，開發環境、質量、安全問題及團隊協作問題均可在 VS Code 中解決，并在關鍵的流程節點來把控代碼的質量，深度和 DEF 團隊合作形成閉環。

同時我們正在籌劃淘系前端最佳實踐的 ESLint 規范，結合?eslint-config-ali?及和各個團隊的質量接口人共同制定出更適合淘系前端團隊的 ESLint 規范。(歡迎私信我 進行共建哦~)

我們還將為有需要的團隊提供研發數據服務支持，管理查詢項目質量的同時，可以配置定制更符合團隊需要的質量解決方案及發布卡口，發布公告等。

?

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的在淘宝，我们是这样衡量代码质量的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。