高質(zhì)量代碼的評(píng)判標(biāo)準(zhǔn)有哪些？

敲了十多年代碼，做的項(xiàng)目大多數(shù)也都是和業(yè)務(wù)相關(guān)的系統(tǒng)，并沒有什么高深的算法，但是就算是簡單的業(yè)務(wù)邏輯，代碼也會(huì)分成三六九等，下面我就說說我對(duì)好代碼和爛代碼的看法。

完善的邏輯，做個(gè)悲觀主義者

按照需求實(shí)現(xiàn)代碼邏輯，這算是達(dá)到了及格線，如果想更進(jìn)一步的話，我認(rèn)為至少要做到以下幾點(diǎn)：

各種情況都需要考慮到，并做相應(yīng)的處理；比如頁面進(jìn)行性別的轉(zhuǎn)碼，需求要求M=男F=女，那么你需要考慮除了這兩種情況，會(huì)不會(huì)有其他的數(shù)據(jù)？會(huì)不會(huì)有為空的數(shù)據(jù)？如果遇到這樣的數(shù)據(jù)頁面需要如何展示；開發(fā)要按照需求開發(fā)，但是不能只按照需求開發(fā)；

不要相信其他的系統(tǒng)，比如開發(fā)一個(gè)接口，入?yún)⑹堑卿汭D，出參是查詢到的用戶信息，接口文檔中已經(jīng)標(biāo)注【入?yún)⒉荒転榭铡浚敲词羌南Ｍ谡{(diào)用方做非空判斷，還是接口代碼的第一步做非空判斷呢？當(dāng)然是“不能相信別人”了；

如果單純地滿足需求的代碼是60分及格的話，能做到這一步能給到70分。

關(guān)注實(shí)現(xiàn)，也要關(guān)注效率

我?guī)н^不少項(xiàng)目，遇到過很多次這樣的問題：代碼在本地或測試環(huán)境運(yùn)行無問題，但是一發(fā)布到生產(chǎn)環(huán)境，卻直接崩潰了；或者本來很快就能返回的頁面或接口，在生產(chǎn)環(huán)境卻要很長時(shí)間才能返回；這些都是因?yàn)楹鲆暳松a(chǎn)環(huán)境和測試環(huán)境的差異造成的：

數(shù)據(jù)量的差異，造成SQL執(zhí)行時(shí)間差距很大，這是我遇到過最多的問題；很多開發(fā)人員習(xí)慣寫復(fù)雜的SQL、多表關(guān)聯(lián)，甚至一些計(jì)算都喜歡用數(shù)據(jù)庫函數(shù)實(shí)現(xiàn)，因?yàn)樗麄冋J(rèn)為通過SQL實(shí)現(xiàn)起來更容易一些，但是這其實(shí)埋下了隱患，測試環(huán)境萬級(jí)的數(shù)據(jù)量，SQL怎么寫都跑的很快，但是生產(chǎn)環(huán)境數(shù)據(jù)量翻了幾十倍、上百倍，這樣的SQL當(dāng)然就執(zhí)行不動(dòng)了；我通常會(huì)讓開發(fā)人員在敲完代碼之后，把SQL單獨(dú)拿出來去生產(chǎn)環(huán)境跑跑試試，提前發(fā)現(xiàn)問題（要是有準(zhǔn)生產(chǎn)環(huán)境就更好了）；

訪問量的差異，比如開發(fā)一個(gè)接口，測試的時(shí)候只有幾個(gè)測試人員點(diǎn)一點(diǎn)，只能測試出功能邏輯，如果接口有性能問題，必然無法暴露；所以上線前的壓力測試是必不可少的；

做到這一步，我能給到80分。

增加代碼的可讀性

代碼的可讀性非常重要，因?yàn)槟愕拇a不僅僅是自己能看懂就可以了，還需要組內(nèi)其他開發(fā)人員能看懂，甚至需要項(xiàng)目組的人都換了一遍，新來的開發(fā)人員也能看懂。

遵從書寫規(guī)范，遵守命名規(guī)范，變量名、方法名見名知意，寫注釋，這些都是最基本的要求；

避免“炫技”，減少毫無必要的復(fù)雜，比如，有些開發(fā)人員在學(xué)習(xí)了一種設(shè)計(jì)模式的時(shí)候，不考慮場景是否合適，非要加到代碼中，這除了降低了代碼的復(fù)雜度，除此之外毫無意義；

合理的代碼分層、分包，也可以增加代碼的可讀性和可維護(hù)性；

如果能做到這一步，我覺得就可以得到90分了。

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。