點擊上方 IT牧場 ,選擇 置頂或者星標技術乾貨每日送達!
好的代碼一定是整潔的,並且能夠幫助閱讀的人快速理解和定位。好的代碼可以加快應用的開發迭代速度,不必花過多的時間來修復 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 個維度通過加權平均的方式計算項目質量分,並根據木桶效應,在計算得分的過程中加大了最低分的權重,得出最終項目質量評分。
項目地址
github地址:github.com/ice-lab/iceworks/tree/master/
PS:
歡迎在留言區留下你的觀點,一起討論提高。如果今天的文章讓你有新的啓發,歡迎轉發分享給更多人。
乾貨分享
最近將個人學習筆記整理成冊,使用PDF分享。關注我,回覆如下代碼,即可獲得百度盤地址,無套路領取!
•001:《Java併發與高併發解決方案》學習筆記;•002:《深入JVM內核——原理、診斷與優化》學習筆記;•003:《Java面試寶典》•004:《Docker開源書》•005:《Kubernetes開源書》•006:《DDD速成(領域驅動設計速成)》•007:全部•008:加技術羣討論
近期熱文
•LinkedBlockingQueue vs ConcurrentLinkedQueue•解讀Java 8 中爲併發而生的 ConcurrentHashMap•Redis性能監控指標彙總•最全的DevOps工具集合,再也不怕選型了!•微服務架構下,解決數據庫跨庫查詢的一些思路•聊聊大廠面試官必問的 MySQL 鎖機制
關注我
喜歡就點個"在看"唄^_^