淘寶開源的程式碼質量檢測工具，太強大了
前言
好的程式碼一定是整潔的，並且能夠幫助閱讀的人快速理解和定位。好的程式碼可以加快應用的開發迭代速度，不必花過多的時間來修復 bug 和完善程式碼。
好的程式碼不但能夠使得新的專案成員更容易加入專案，同時方便專案組成員快速做好 Back up。好的程式碼便於促進團隊間交流合作提升開發效率。
程式碼質量評價標準
有編碼經驗的人對程式碼都有一定的“鑑賞力”，能夠憑感覺給出程式碼好壞的主觀評價。但是這種憑感覺的方式太過個性隨意，所謂仁者見仁智者見智，很難達成共識，那有沒有一種公認的標準來鑑定程式碼質量呢？
答案是有的。這裡簡單分享當下較常用的評價標準，其中包括：編碼規範、可讀性、可維護性、重複度及可測試性。
編碼規範主要包含是否遵守了最佳實踐和團隊編碼規範，是否包含可能出問題的程式碼，以及可能存在安全的漏洞。編碼規範有助於提高團隊內協助的效率以及程式碼的可維護性。
可讀性Code Review 是一個很好的測驗程式碼可讀性的手段。如果你的同事可以輕鬆地讀懂你寫的程式碼，那說明你的程式碼可讀性很好；反之則說明你的程式碼可讀性有待提高了。遵守編碼規範也能讓我們寫出可讀性更好的程式碼。
可維護性程式碼的可維護性是由很多因素協同作用的結果。程式碼的可讀性好、簡潔、可擴充套件性好，就會使得程式碼易維護；更細化地講，如果程式碼分層清晰、模組化好、高內聚低耦合、遵從基於介面而非實現程式設計的設計原則等等，那就可能意味著程式碼易維護。除此之外，程式碼的易維護性還跟專案程式碼量的多少、業務的複雜程度、利用到的技術的複雜程度、文件是否全面等諸多因素有關。
重複度遵守 Don’t Repeat Yourself 原則，儘量減少重複程式碼的編寫，複用已有的程式碼。對專案定期進行程式碼重複度檢測是一個很有意義的事，可以幫助開發人員發現冗餘程式碼，進行程式碼抽象和重構。重複的程式碼一旦出錯，意味著加倍的工作量和持續的不可控。如果程式碼中有大量的重複程式碼，就要考慮將重複的程式碼提取出來，封裝成公共的方法或者元件。
可測試性程式碼可測試性的好壞，同樣可以反應程式碼質量的好壞。程式碼的可測試性差，比較難寫單元測試，那基本上就能說明程式碼設計得有問題。
除此之外還有很多程式碼質量評價標準。我們需要一些取捨，選取部分大家有共識的規則定義團隊好的程式碼標準。
程式碼質量維度
當前版本通過 @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 個維度通過加權平均的方式計算專案質量分，並根據木桶效應，在計算得分的過程中加大了最低分的權重，得出最終專案質量評分。