项目重构实践

重构的定义

我理解的重构是在不改变业务逻辑的基础上，修改代码实现，让其具有更好的可读性、可扩展性。要保证不改变业务逻辑是前提。有可能一次重构把正常的业务逻辑改坏了，搞成了线上故障。怎样保障这个前提呢？那就是充分的单测。有了单测的保证，采用小步快跑的方式，逐步重构。每完成一个小的修改，就运行一次单测。逐步重构可以让你快速发现问题，当一次单测失败了，你就知道是这次改动导致了bug。如果进行了多处修改，再运行单测，此时定位bug是哪处变更导致的，将花费更多的时间。这是逐步单测带来的好处，让你快速定位bug。有一句话叫做，无单测不重构。因为没有了单测的保障，你没有信心保证重构不会导致业务逻辑错误。但是，重构仅仅是为了让代码更优雅，不会带来直接的产品功能增量。甚至因为花时间重构导致占用了需求开发的时间，所以除了程序员之外其他角色往往不关心重构甚至抵制重构，这就导致了坚持重构的程序员往往成了孤勇者。

重构的时机

什么时候进行重构呢？有人认为重构与开发是冲突的。必须暂停所有进行中的需求迭代，然后投入一批人，基于某个版本进行代码重写。往往这样的重构往往是灾难性的，可以参考软件行业永远不要做的事这篇文章。恰恰相反，重构是一个可以融入日常开发迭代的事，每一次需求迭代都是重构的时机。当你面对项目的代码准备开发一个新的需求了，实现的过程中，你发现基于现有的实现很难实现本次业务需求，或者即使可以实现业务需求，但是要写很多恶心的定制代码，或者目前的代码实现刚好适用于某个设计模式的场景。使用设计模式改造后，更简洁，更容易理解，日后更好修改。当遇到上述几种场景的时候，代表着是时候进行重构了。

重构的好处

为什么要重构呢？作为写过几年代码的同学，你肯定看到过一团乱麻的代码。修改这种代码的感觉，有种如履薄冰的感觉。甚至达到了牵一发而动全身的地步。这种代码往往耦合度很高。单个类职责居多，往往既做了A事，又做了B事，还做了C事。当你想复用A逻辑的时候，你发现这段代码很难被单独执行，无法被单独复用。面向对象的语言带来的一个好处就是提高了代码的复用性，降低了开发人员的理解成本。一个组件的使用者不需要了解组件的实现细节，只需要拿到对象的引用就可以使用该对象提供的能力。当然，这种情况的前提是优良的设计。有一个普遍存在的误区，我使用了面向对象的语言，所以我写的代码就是面向对象的代码。我见过的很多开发项目，虽然使用了Java，但是本质上是面向过程编程的，属于事务脚本范畴，跟面向对象相差甚远。一个简单的检验标准是，代码实现是否使用到了接口、继承、多态、封装这些语言特征。很多实现都是业务逻辑的堆叠，缺乏合理的设计。业界有一个用于衡量软件质量的标准-SOLID原则，也就是设计原则。包括，开闭原则、单一职责原则、接口隔离、依赖倒置、里氏替换原则。符合这些标准的软件，软件质量肯定是高的。设计原则是目标，重构、设计模式、领域设计是具体的实现手段。

重构实践

说了这么多，都是比较虚的理论。在实际项目中怎么具体操作呢？下面就结合自己最近开发的项目，说下自己的理解。

项目背景

简单的讲就是目前业务功能依赖的服务A改成服务B。现状如图，后端提供了一批标准的服务，这些服务注册在网关中。基于接口定义有一批服务实现。本次项目会将业务领域层的服务实现进行重构，下面会介绍一下重构过程中的遇到的一些典型问题和自己的解决办法，提供给大家参考，期望达到抛砖引玉的作用。

现状

目标

参数校验

现有实现

我们在实现对外服务时，第一步往往要做参数校验。因为是对外提供的服务，调用方提供的入参五花八门，虽然会约定协议，但没法保证每个调用方都是严格按照协议传参。所以，对于入参的校验是不可或缺的。下面的参数校验是比较典型的实现方式，对必填参数就行校验，校验不通过就返回错误提示。如果这种校验逻辑比较少，是可以接受的。但是当我们提供了大量服务，每个服务都有这么一段逻辑。我们就要考虑下，是不是有统一的解决办法。

@Override
    public BaseResponse<Knowledge> getKnowledgeDetail(KnowledgeRequest request) {
        if (request == null) {
            return ResponseUtils.error(null, PaasResponseEnum.MISSING_PARAMETER, "Request");
        }
        if (StringUtils.isEmpty(request.getTenantId())) {
            return ResponseUtils.error(request.getRequestId(), PaasResponseEnum.MISSING_PARAMETER, "RobotCode");
        }
        if (request.getKnowledgeId() == null) {
            return ResponseUtils.error(request.getRequestId(), PaasResponseEnum.MISSING_PARAMETER, "KnowledgeId");
        }
        ...
     }   

解决方案

对于校验这块，java软件生态是有成熟的解决方案的。那就是java校验规范，validation-api。

jsr规范请求 JSR是Java Specification Requests的缩写，意思是Java 规范提案。 是指向JCP(Java Community Process)提出新增一个标准化技术规范的正式请求。

这套校验规范定义了，校验所需要的基本实体和接口。类似于servlet-api，委员会只定义规范，不提供实现。就像tomcat是基于servlet-api实现的servlet容器一样。hibernate-validator是对java参数校验规范的一种实现。

实践

在项目中引入如下依赖。如果是SpringBoot应用的话，SpringBoot检测到有hibernate-validator的依赖，就会进行自动装配，帮我们初始化好需要的bean。我们在业务代码中只要注入javax.validation.Validator实例就可以进行校验逻辑了。

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator</artifactId>
</dependenc

所以上面的校验实现可以实现为下面这样。

第一步声明字段应该满足什么约束。我们使用注解规定tenantId和knowledgeId必须非空，并且knowledgeId必须大于等于1。

class KnowledgeRequest {
    @NotNull
    private String tenantId;
    
    @NotNull(groups = {SingleKnowledgeGroup.class, AddSolutionGroup.class})
    @Min(groups = AddSolutionGroup.class, value = 1)
    private Long knowledgeId;
}

第二步调用框架进行校验。我们上面定义的规则叫做约束，约束是分组的。不