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

好的代碼一定是整潔的,並且能夠幫助閱讀的人快速理解和定位。好的代碼可以加快應用的開發迭代速度,不必花過多的時間來修復 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/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章