关于提高代码可维护性的一点思考

为什么需要提高代码的可维护性

​ 因为在平时开发项目过程中，因为项目工期紧、需求变化频繁等等原因，然后导致代码混乱、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;
      }
  }
  复制代码

  ​ 根据上面的代码，我们只需要自行实现监听器，然后就可以完成创建订单后的业务操作。这样就达到了一个解耦的效果。会不会更好？