淘寶開源的代碼質量檢測工具，太強大了！！

好的代碼必定是整潔的，而且可以幫助閱讀的人快速理解和定位。好的代碼能夠加快應用的開發迭代速度，沒必要花過多的時間來修復 bug 和完善代碼。

好的代碼不但可以使得新的項目成員更容易加入項目，同時方便項目組成員快速作好 Back up。好的代碼便於促進團隊間交流合做提高開發效率。

代碼質量評價標準

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

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

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

可讀性
Code Review 是一個很好的測驗代碼可讀性的手段。若是你的同事能夠輕鬆地讀懂你寫的代碼，那說明你的代碼可讀性很好；反之則說明你的代碼可讀性有待提升了。遵照編碼規範也能讓咱們寫出可讀性更好的代碼。

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

重複度
遵照 Don’t Repeat Yourself 原則，儘可能減小重複代碼的編寫，複用已有的代碼。對項目按期進行代碼重複度檢測是一個頗有意義的事，能夠幫助開發人員發現冗餘代碼，進行代碼抽象和重構。重複的代碼一旦出錯，意味着加倍的工做量和持續的不可控。若是代碼中有大量的重複代碼，就要考慮將重複的代碼提取出來，封裝成公共的方法或者組件。

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

除此以外還有不少代碼質量評價標準。咱們須要一些取捨，選取部分你們有共識的規則定義團隊好的代碼標準。

代碼質量維度

當前版本經過 @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 個維度經過加權平均的方式計算項目質量分，並根據木桶效應，在計算得分的過程當中加大了最低分的權重，得出最終項目質量評分。

項目地址
github地址：https://github.com/ice-lab/iceworks/tree/master/

來源：github.com/ice-lab/iceworks/tree/master/