為什麼需要提高程式碼的可維護性
因為在平時開發專案過程中，因為專案工期緊、需求變化頻繁等等原因，然後導致程式碼混亂、service臃腫，最後導致維護成本高維護人員怨聲載道，最壞結果可能需要重構。
如何提高程式碼可維護性
-
開發之前建模
寫程式碼之前最好建模，把整個業務流程清晰在圖形當中展示，以便自己加深對業務的理解同時對整個業務程式碼的掌控。
-
合理的歸類
為什麼需要合理的歸類，大多數我們都只開發entity,dao,service,controller等四層，那麼這樣會隨著專案不斷的迭代導致類太臃腫。
那麼我們就需要在這四層的基礎上再豐富一些。
例如：
1.加入job任務包
2.加入utils工具類包
3.加入handler處理器
以上歸類只是給大家提供一點思路，具體業務場景還需分析。其實這些在一些優秀的開源專案當中都有體現。大家只需要看看學習理解，然後照搬過來即可。這也是為什麼需要看原始碼的原因，個人覺得看原始碼不緊緊是熟悉整個執行過程有助於排查問題過程。更重要的是學習裡面的設計思路。
-
合理的引入一些設計模式
設計模式是老生常談的話題了，面試當中也會問。那麼問題來了在什麼時候引入設計模式呢？
舉個例子：
假設我們在開發一個訂單功能，此時需要建立一個訂單，建立好訂單後需要給使用者傳送簡訊啊一系列操作。
常規開發可能就是在一個方法裡面或者在一個service裡面拆幾個小方法搞定了。
其實在這個場景我推薦大家使用事件機制也就是觀察者模式去實現，為什麼？本身客戶端是發起建立訂單的操作，傳送簡訊的等操作其實在這個時候和訂單沒關係，是在產生訂單後的操作。如果大家有用spring,那麼可以借用spring已經實現的來實現。
@Service public class PaymentOrderServiceImpl implements PaymentOrderService { @Autowired private ApplicationEventPublisher applicationEventPublisher; public PaymentOrder createOrder(PaymentOrder paymentOrder){ //完成建立訂單後發起事件 applicationEventPublisher.publishEvent(new PaymentOrderEvent(paymentOrder)); return paymentOrder; } } 複製程式碼 根據上面的程式碼，我們只需要自行實現監聽器，然後就可以完成建立訂單後的業務操作。這樣就達到了一個解耦的效果。會不會更好？