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

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

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

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

不要相信其他的系統，比如開發一個介面，入參是登入ID，出參是查詢到的使用者資訊，介面文件中已經標註【入參不能為空】，那麼是寄希望於呼叫方做非空判斷，還是介面程式碼的第一步做非空判斷呢？當然是“不能相信別人”了；

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

關注實現，也要關注效率

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

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

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

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

增加程式碼的可讀性

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

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

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

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

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

最本質的思考

要明白高質量程式碼的要求，我們透過最本質的思考來推導：

程式碼是要人寫完，然後交給機器去執行的，因此要求執行時的高質量;同時寫完的程式碼要隨著業務的變更而變化，因此要求維護時的高質量;一段程式碼隨著時間流逝，開發者有可能會遺忘某些細節，同時一段程式碼不可能一直是一個人維護，有閱讀程式碼的需求，因此要求可讀性的高質量。

下面分別詳細闡述。

執行時的高質量

程式是拿來用的，因此，保證執行狀態下的高質量是最重要的，主要有以下三個方面：

1. 準確性：程式可以準確的執行並輸出結果。要求考慮針對輸入的引數進行各種校驗，包括非空校驗與正確性校驗（比如手機號格式的正確性，使用者編號一定是系統中存在的等等），一定不能相信呼叫方，要在方法內部做好防範措施。2. 容錯性：這是對系統提出一個更高的要求，是系統可以平穩執行的必要條件，也是可以更好的保證系統的準確性的必要條件。不能呼叫方傳一個空值系統就掛掉；有併發請求進來，系統不能出現髒資料，要有分散式鎖等等。3. 效能：這是系統可以持續提供服務的保障1. 能抗住生產上的訪問量，生產上的查詢sql響應時間不會過長；2. 不能時不時的宕機比如一些特定引數的請求，會消耗大量的程式記憶體；比如一個 insert select 就產生了上個間隙鎖，導致大量資料庫請求等待閱讀與可維護的高質量1. 要求包結構要清晰

務必進行分層，分層是防止程式失控並全面腐化的一個良藥，他隔絕了不同層之間可能的傳染；底層保持精簡與通用性，複雜度隨著層級往上逐漸遞增。示意圖如下：

2. 命名要規範

命名要規範，且專案中的命名規範要一致，包括：包，類，變數，方法

3. 該重用的程式碼要進行重用

當一段程式碼重複出現兩次以上就有必要進行抽象了；這裡推薦一下idea 整合開發環境，它可以自動提示出重複出現的程式碼，當然其它整合開發環境可能也有，沒有調查過，各位可以嘗試。

4. 所用技術與程式碼結構儘量簡單

用最簡單的邏輯，實現最強大的功能；

能不引入外部依賴實現的，就不引入，畢竟依賴越多，系統越複雜，問題越多；

程式碼結構儘量簡單：不要引入不必要的設計模式與複雜的程式碼結構；慎用繼承，繼承是面象物件語言的一大特性，為什麼說要慎用呢？

理論上繼承要達到的目標都可以用組合實現（慎用，不是不用），且更靈活，也更清晰；因為繼承會導致多型，繼承如果用的不當，繼承層次不清晰，或者繼承鏈過長，最終一個例項宣告出來，你都不知道用的是哪個態；而且子類可級聯呼叫父類方法，父類也可以呼叫子類方法，最終的方法呼叫鏈， 子類與父類之間跳來跳去，會把你給搞暈掉，具體可以看下面的示意圖。

5.程式碼要保持高內聚與低耦合

此即面象物件三大特性之一的封裝：隱藏細節，隱藏一些外部用不到，不必要知道的資訊，能自己取到的就自己獲取；隱藏或遮蔽敏感操作，對於一些敏感操作，要不暴露在外，或者對這些操作時，要有許可權控制，業務邏輯約束，不要相信外部的任何呼叫方。

總結

總結一下，要弄清楚高質量程式碼的評判標準，要從寫程式碼的根本目的作為出發點，從程式執行與程式碼可讀性與可維護性為基本原則去考慮，法無定法，在程式碼開發過程中，要時刻銘記這些基本原則。

我認為我們首先要理解什麼是高質量的程式碼，以下是我總結的幾點：

程式碼規範性

程式碼有沒有標準規範，是他人第一眼就能看見的，程式碼規範是一個程式設計師的臉面，所以要有編碼命名，類命名、包命名等一系列的標準規範，這樣程式碼才看起來美觀，也是評價高質量程式碼標準之一。

程式碼複用性

程式碼中如果有大量的可重複利用的方法時，就要考慮進行封裝，把這些方法封裝成一個功能類，這樣程式碼看起來就會簡潔清晰，這也評價高質量程式碼標準之一。

程式碼可讀性

程式碼邏輯一定要清晰易懂，不要寫的過於複雜，如果太長要考慮拆分，產品是不斷完善的，它時時刻刻都在發生著變化，所以程式碼可讀性是非常重要的，這樣他人在變更你的程式碼時不會手足無措，這也評價高質量程式碼標準之一。

程式碼功能性

程式碼功能性就是要考慮程式碼中是否有影響效能的地方，如果有影響就要重新梳理邏輯，提升程式碼的功能性，這也評價高質量程式碼標準之一。

綜上所述，程式碼規範性、複用性、可讀性、功能性可以幫助產品提升質量，高質量程式碼開發出來的產品才能穩定不出錯、高效更方便的使用，客戶才能認同為其買單。