敲了十多年代碼，做的項目大多數(shù)也都是和業(yè)務相關的系統(tǒng)，并沒有什么高深的算法，但是就算是簡單的業(yè)務邏輯，代碼也會分成三六九等，下面我就說說我對好代碼和爛代碼的看法。
完善的邏輯，做個悲觀主義者
按照需求實現(xiàn)代碼邏輯，這算是達到了及格線，如果想更進一步的話，我認為至少要做到以下幾點：
各種情況都需要考慮到，并做相應的處理；比如頁面進行性別的轉碼，需求要求M=男F=女，那么你需要考慮除了這兩種情況，會不會有其他的數(shù)據(jù)？會不會有為空的數(shù)據(jù)？如果遇到這樣的數(shù)據(jù)頁面需要如何展示；開發(fā)要按照需求開發(fā)，但是不能只按照需求開發(fā)；
不要相信其他的系統(tǒng)，比如開發(fā)一個接口，入?yún)⑹堑卿汭D，出參是查詢到的用戶信息，接口文檔中已經(jīng)標注【入?yún)⒉荒転榭铡浚敲词羌南Ｍ谡{(diào)用方做非空判斷，還是接口代碼的第一步做非空判斷呢？當然是“不能相信別人”了；
關注實現(xiàn)，也要關注效率
我?guī)н^不少項目，遇到過很多次這樣的問題：代碼在本地或測試環(huán)境運行無問題，但是一發(fā)布到生產(chǎn)環(huán)境，卻直接崩潰了；或者本來很快就能返回的頁面或接口，在生產(chǎn)環(huán)境卻要很長時間才能返回；這些都是因為忽視了生產(chǎn)環(huán)境和測試環(huán)境的差異造成的：
數(shù)據(jù)量的差異，造成SQL執(zhí)行時間差距很大，這是我遇到過最多的問題；很多開發(fā)人員習慣寫復雜的SQL、多表關聯(lián)，甚至一些計算都喜歡用數(shù)據(jù)庫函數(shù)實現(xiàn)，因為他們認為通過SQL實現(xiàn)起來更容易一些，但是這其實埋下了隱患，測試環(huán)境萬級的數(shù)據(jù)量，SQL怎么寫都跑的很快，但是生產(chǎn)環(huán)境數(shù)據(jù)量翻了幾十倍、上百倍，這樣的SQL當然就執(zhí)行不動了；我通常會讓開發(fā)人員在敲完代碼之后，把SQL單獨拿出來去生產(chǎn)環(huán)境跑跑試試，提前發(fā)現(xiàn)問題（要是有準生產(chǎn)環(huán)境就更好了）；
訪問量的差異，比如開發(fā)一個接口，測試的時候只有幾個測試人員點一點，只能測試出功能邏輯，如果接口有性能問題，必然無法暴露；所以上線前的壓力測試是必不可少的；
增加代碼的可讀性
代碼的可讀性非常重要，因為你的代碼不僅僅是自己能看懂就可以了，還需要組內(nèi)其他開發(fā)人員能看懂，甚至需要項目組的人都換了一遍，新來的開發(fā)人員也能看懂。
遵從書寫規(guī)范，遵守命名規(guī)范，變量名、方法名見名知意，寫注釋，這些都是最基本的要求；
避免“炫技”，減少毫無必要的復雜，比如，有些開發(fā)人員在學習了一種設計模式的時候，不考慮場景是否合適，非要加到代碼中，這除了降低了代碼的復雜度，除此之外毫無意義；
合理的代碼分層、分包，也可以增加代碼的可讀性和可維護性；