高質量代碼的評判標準有哪些？

敲了十多年代碼，做的項目大多數也都是和業務相關的系統，并沒有什么高深的算法，但是就算是簡單的業務邏輯，代碼也會分成三六九等，下面我就說說我對好代碼和爛代碼的看法。

完善的邏輯，做個悲觀主義者

按照需求實現代碼邏輯，這算是達到了及格線，如果想更進一步的話，我認為至少要做到以下幾點：

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

不要相信其他的系統，比如開發一個接口，入參是登錄ID，出參是查詢到的用戶信息，接口文檔中已經標注【入參不能為空】，那么是寄希望于調用方做非空判斷，還是接口代碼的第一步做非空判斷呢？當然是“不能相信別人”了；

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

關注實現，也要關注效率

我帶過不少項目，遇到過很多次這樣的問題：代碼在本地或測試環境運行無問題，但是一發布到生產環境，卻直接崩潰了；或者本來很快就能返回的頁面或接口，在生產環境卻要很長時間才能返回；這些都是因為忽視了生產環境和測試環境的差異造成的：

數據量的差異，造成SQL執行時間差距很大，這是我遇到過最多的問題；很多開發人員習慣寫復雜的SQL、多表關聯，甚至一些計算都喜歡用數據庫函數實現，因為他們認為通過SQL實現起來更容易一些，但是這其實埋下了隱患，測試環境萬級的數據量，SQL怎么寫都跑的很快，但是生產環境數據量翻了幾十倍、上百倍，這樣的SQL當然就執行不動了；我通常會讓開發人員在敲完代碼之后，把SQL單獨拿出來去生產環境跑跑試試，提前發現問題（要是有準生產環境就更好了）；

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

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

增加代碼的可讀性

代碼的可讀性非常重要，因為你的代碼不僅僅是自己能看懂就可以了，還需要組內其他開發人員能看懂，甚至需要項目組的人都換了一遍，新來的開發人員也能看懂。

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

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

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

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

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。