關於提升代碼可維護性的一點思考

爲何須要提升代碼的可維護性

​ 由於在平時開發項目過程當中，由於項目工期緊、需求變化頻繁等等緣由，而後致使代碼混亂、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;
      }
  }
  複製代碼

  ​ 根據上面的代碼，咱們只須要自行實現監聽器，而後就能夠完成建立訂單後的業務操做。這樣就達到了一個解耦的效果。會不會更好？