越高級別的程式設計師往往越看重程式碼質量。

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

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 個維度對程式碼進行評分：

1. 最佳實踐：通過 @iceworks/eslint-plugin-best-practices 分析專案，提出符合當前工程特徵（對 ice 和 Rax 專案友好）的最佳實踐及阻塞問題釋出卡口，幫助開發者優化專案效能，避免潛在 bug 。
2. 安全實踐：通過 @iceworks/eslint-plugin-security-practices 掃碼程式碼檢測工程中可能存在的安全風險，包含 url 、敏感成詞、明文賬密資訊及 npm 保證書檢測，降低專案安全風險，守衛專案安全。
3. 阿里程式碼規範：這一維度主要反饋開發人員對於 eslint-config-ali 阿里開發規約的遵守程度。
4. 可維護度：通過 typhonjs-escomplex 對檔案進行掃碼，得出每個檔案的可維護度，可讀性及複雜度評分。針對得分較差的檔案可以進行深度分析幫助開發者更好的重構複雜程式碼。
5. 重複度：通過 jscpd 計算重複出現的程式碼區塊佔比，計算出 clone 分數。並逐一列舉重複的程式碼，方便開發者快速定位重複程式碼，將其封裝成公共的方法或者元件。

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

快來使用 Iceworks Doctor 測測自己專案的得分，比比誰的分數高吧~

問題修復

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

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

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

前進方向思考

願景：讓團隊沒有不及格（低於60分）的程式碼。

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

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

原文連結

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