天天看點

阿裡開源代碼品質檢測工具!

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

​​關注微信公衆号:網際網路架構師,在背景回複:2T,可以擷取我整理的教程,都是幹貨。​​

​猜你喜歡​

​1、​​GitHub 标星 3.2w!史上最全技術人員面試手冊!FackBoo發起和總結​​

​2、​​如何才能成為優秀的架構師?​​

​3、​​從零開始搭建創業公司背景技術棧​​

​4、​​程式員一般可以從什麼平台接私活?​​

​5、​​37歲程式員被裁,120天沒找到工作,無奈去小公司,結果懵了...​​

​6、​​滴滴業務中台建構實踐,首次曝光​​

繼續閱讀