代碼質(zhì)量評價標(biāo)準(zhǔn)

有編碼經(jīng)驗的人對代碼都有一定的“鑒賞力”，能夠憑感覺給出代碼好壞的主觀評價。但是這種憑感覺的方式太過個性隨意，所謂仁者見仁智者見智，很難達成共識，那有沒有一種公認的標(biāo)準(zhǔn)來鑒定代碼質(zhì)量呢？
答案是有的。這里簡單分享當(dāng)下較常用的評價標(biāo)準(zhǔn)，其中包括：編碼規(guī)范、可讀性、可維護性、重復(fù)度及可測試性。
編碼規(guī)范
主要包含是否遵守了最佳實踐和團隊編碼規(guī)范，是否包含可能出問題的代碼，以及可能存在安全的漏洞。編碼規(guī)范有助于提高團隊內(nèi)協(xié)助的效率以及代碼的可維護性。
可讀性
Code Review 是一個很好的測驗代碼可讀性的手段。如果你的同事可以輕松地讀懂你寫的代碼，那說明你的代碼可讀性很好；反之則說明你的代碼可讀性有待提高了。遵守編碼規(guī)范也能讓我們寫出可讀性更好的代碼。
可維護性
代碼的可維護性是由很多因素協(xié)同作用的結(jié)果。代碼的可讀性好、簡潔、可擴展性好，就會使得代碼易維護；更細化地講，如果代碼分層清晰、模塊化好、高內(nèi)聚低耦合、遵從基于接口而非實現(xiàn)編程的設(shè)計原則等等，那就可能意味著代碼易維護。除此之外，代碼的易維護性還跟項目代碼量的多少、業(yè)務(wù)的復(fù)雜程度、利用到的技術(shù)的復(fù)雜程度、文檔是否全面等諸多因素有關(guān)。

重復(fù)度遵守 Don’t Repeat Yourself 原則，盡量減少重復(fù)代碼的編寫，復(fù)用已有的代碼。對項目定期進行代碼重復(fù)度檢測是一個很有意義的事，可以幫助開發(fā)人員發(fā)現(xiàn)冗余代碼，進行代碼抽象和重構(gòu)。重復(fù)的代碼一旦出錯，意味著加倍的工作量和持續(xù)的不可控。如果代碼中有大量的重復(fù)代碼，就要考慮將重復(fù)的代碼提取出來，封裝成公共的方法或者組件。可測試性

代碼質(zhì)量維度

1. 最佳實踐： 通過 @iceworks/eslint-plugin-best-practices 分析項目，提出符合當(dāng)前工程特征（對 ice 和 Rax項目友好）的最佳實踐及阻塞問題發(fā)布卡口，幫助開發(fā)者優(yōu)化項目性能，避免潛在 bug 。
   
2. 安全實踐： 通過 @iceworks/eslint-plugin-security-practices 掃碼代碼檢測工程中可能存在的安全風(fēng)險，包含 url 、敏感成詞、明文賬密信息及 npm 包證書檢測，降低項目安全風(fēng)險，守衛(wèi)項目安全。
   
3. 阿里代碼規(guī)范： 這一維度主要反饋開發(fā)人員對于 eslint-config-ali 阿里開發(fā)規(guī)約的遵守程度。
   
4. 可維護度： 通過 typhonjs-escomplex 對文件進行掃碼，得出每個文件的可維護度，可讀性及復(fù)雜度評分。針對得分較差的文件可以進行深度分析幫助開發(fā)者更好的重構(gòu)復(fù)雜代碼。
   
5. 重復(fù)度： 通過 jscpd 計算重復(fù)出現(xiàn)的代碼區(qū)塊占比，計算出 clone 分數(shù)。并逐一列舉重復(fù)的代碼，方便開發(fā)者快速定位重復(fù)代碼，將其封裝成公共的方法或者組件。
   

項目地址

版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)者所有。除非無法確認，我們都會標(biāo)明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并表示歉意。謝謝!