代碼的設計是否符合設計要求
- 業務邏輯是否正確：業務流程是否按照詳細設計的流程走，不要出現原本是先A流程後B流程而設計的時候出現先B後A，或者丟失流程。
- 某些傳入參數是否合理：判斷某些接口的參數輸入是否是冗餘的，比如輸入A字段可以滿足A接口裏面的所有操作，那麼多輸入一個B就冗餘的。
- 某些判斷是否合理，比如某些參數的輸入金額是否可以爲0的判斷等等。
- 是否有異常處理機制，一個好的代碼設計應該考慮各種異常並對相應的異常做出合理的處理，比如接口的可重入，當代碼檢測到有重入的這種情況，怎樣去做這種異常處理使得調用方能捕捉的這些異常而進行後面的處理。
關注業務可拓展性
- 我們的業務在不斷的發展，每一個項目設計都會影響後續業務的拓展，一個好的設計應該考慮到後續業務的發展，而儘量避免定製化的設計。
- 關注使用到的數據結構、設計模式和代碼性能：
一個好的數據結構和設計模式可以增加代碼的可維護性安全性和效率等，比如我們在設計的時候要考慮到不同的場景選擇什麼樣的數據結構，有時候我們會糾結於用map還是用hash_map，這時候我們要根據具體的情況具體分析； - 當我們設計代碼的時候如果能用上系統提供的函數那麼最好不要自己去寫
- 某些設計如果能套用設計模式會讓設計更加美觀也讓閱讀者更加明瞭；出於對系統性能的考量，我們要關注編寫代碼對系統的開銷，包括使用的算法是否合理，以及對某些比較耗時的操作比如數據庫的操作要加以關注。
檢查代碼可讀性和可維護性
- 如果代碼的可讀性強，那麼維護起來也就方便很多；一個好的代碼規範和編碼風格會節省大家對代碼的理解時間，減少維護成本；雖然我們有編程規範檢查工具，但有些內容檢查不出來，是需要靠大家去規範的。
- 關注代碼註釋：我們在編寫函數和進行邏輯判斷的時候最好要標註一下這個函數或者這段判斷是用來做什麼的；做了這種註釋的好處，一來當別人閱讀這段代碼的時候看到你的註釋以後就會根據你的思路快速理解代碼，甚至不閱讀直接跳過；二來防止自己由於長時間不閱讀代碼而忘記這段代碼的用途。
- 關注命名規範：雖然我們有自己的編碼規範，但是這種規範只是限制了使用駝峯命名法還是其他命名法；而好的命名風格應該是看到變量或者函數名字就能“望文生義”，畢竟我們不能把自己寫的所有代碼都做註釋。
- 關注重複代碼：如果出現大量的重複性代碼，要考慮將這些代碼抽象出公用函數，以減少代碼量並增強代碼可讀性。
- 關注繁瑣的邏輯：如果一個簡單的功能卻對應大篇幅的代碼，要考慮一下是不是有比較簡單的實現方式，因爲過於複雜的代碼會給後來者的維護帶來麻煩；如果沒有簡略的辦法，一定要把註釋寫好。
參考文章：https://www.jianshu.com/p/e9f9aef9a0e9