軟體環境：Spring MVC + MyBatis
主要展現在兩個方面，一個是編碼習慣問題，另一個是編碼品質的問題。編碼習慣主要有日志編寫、代碼注釋以及編碼風格的問題，而編碼品質則與很多方面相關，比如輪子的使用、資料互動、邏輯精簡程度等等。下面展開來說
編碼習慣問題：
- 方法體偏長，不易管理維護，可逐漸抽取成小方法來減少代碼長度。
- 缺少注釋或注釋與實作不符，這對後期維護人員是個傷害。
- 寫死，随手寫的代碼或測試時的死資料或常見的公共常量未維護，一旦發生變更，維護的代碼量較大
- 日志缺失或缺少或輸出意義不大，一旦發生問題，線上排查難度較大
編碼風格比較個性，讀起來晦澀難懂，對融入團隊是個障礙。
編碼品質問題：
- 重複造輪子的問題，常見工具類使用不到位，經常自己寫方法實作。比如Apache commons，Google Guava等。另一個是共用的業務代碼，未能送出協商好，造成多個版本實作，後期維護成本上升。
- 公共資料使用不充分，存在重複調用的情況，而不是一次調用，多次使用，這種情況在與第三方互動的場景中對效率損傷更大。
- 參數過多時，可轉化為對象傳參，否則一個方法的參數要加大代碼的可維護性。
- 采用MBG産生的單表的關聯查詢，但在業務中适合多表關聯查的情況下，可多表聯查，提高效率。【涉及NDB Cluster存儲引擎，跨庫Join問題】
- 代碼命名，未能見名知意，這也是一個老生常談的問題，起個優雅的名字是多麼的重要。
- 代碼邏輯不順暢，存在走彎路的傾向，能精簡的代碼要反複的重構以達到最優目标。
- 多餘代碼，并無實際意義。如有些情況下，先查詢，再更新，典型的hibernate的思路，完全可以采用以主鍵選擇更新的方法。
- 需要異步處理的情況就不要同步處理，以免影響主業務流程效率。比如流程過程中産生的短信、推送通知等，以通知為主要目的的除外。
- 代碼重複，針對功能類似的方法，可添加一個參數加以區分複用。
- 校驗邏輯要提前，防止做無用功。
- 前後邏輯重複，Controller中作必輸校驗，Service無須再次校驗。
- 雖标記了FIXME/TODO，卻未實際修複，重構不能是一句空話。
何時實施代碼重構：
既然發現了問題，我們又該如何把握好節奏來重構我們的代碼呢？下面推薦幾比較好的重構時機：添加功能時重構、修補錯誤時重構 、複審代碼時重構、時間空餘時重構 。
回頭審視過去的代碼，就像審視我們的過去的編碼思路、技巧，要想有所提升成長，就需要反複來重構，以達到一個最優結果。如果隻是寫過，事後不做複盤重構，對個人成長沒有促進作用。
歡迎加入我的星球
常見Code Review過程中發現的問題
基于SpringCloud的Microservices架構實戰案例
介紹幾款常用的線上API管理工具
你不得不知的幾個網際網路ID生成器方案
Spring Boot + Elasticsearch 實作索引的日常維護
軟體生命周期與技術人的職業周期
