代码优化 1.0

短命女 2023-10-13 21:11 7阅读 0赞

### 1、封装方法形参 ###

当方法形参过多时要封装一个对象出来

### **2、封装业务逻辑** ###

一个方法能写几千行代码，还无任何规则可言…往往负责的人会说，这个业务太复杂，没有办法改善，实际上这都是懒的借口。不管业务再复杂，我们都能够用合理的设计、封装去提升代码可读性。

### **3、判断集合类型不为空的正确方式** ###

CollectionUtils.isEmpty(list)

### 4、集合类型返回值不要 return null ###

Collections.emptyList();

### **5、映射数据库的属性尽量不要用基本类型** ###

比如mybatis返回空值，包装类型默认值是null

### **6、封装判断条件** ###

if（a || b || c）多判断条件是封装好成一个判断方法并加以注释

### **7、使用 @ConfigurationProperties 代替 @Value** ###

### **8、不要在 AService 调用 BMapper** ###

### **9、尽量少写工具类** ###

为什么说要少写工具类，因为写的大部分工具类，在无形中引入的 jar 包里面就有，String 的，Assert 断言的，IO 上传文件，拷贝流的，Bigdecimal 的等等。自己写容易错还要加载多余的类。

### **10、不要包裹 OpenFeign 接口返回值** ###

直接在服务提供方抛异常，而且这样一包装 HTTP 请求永远都是 200，没法做重试和监控。接口响应状态应遵从 HTTP 真实状态

### **11、OpenFeign 接口不建议打成 jar** ###

见过很多使用 OpenFeign 的接口是这样用的，将 OpenFeign 接口写在服务提供方，打成 jar。比如服务 A 调用 B，在 B 项目单独开一个 module 写接口定义，打出一个 jar 包让 A 引入依赖。

让我们来感受一下调用一个 Feign 接口实现的步骤：

1.  在 B 服务中写 Controller 实现
2.  在 B 服务中定义 OpenFeign 接口定义
3.  在 B 服务中修改 jar 版本 +1，打一个 jar 包到本地仓库
4.  在 A 服务中修改依赖 jar 版本，刷新 maven/gradle

乍一看不麻烦是吧？但是要知道我们开发中经常会出现丢参数、缺响应属性等情况，一旦有任何小问题，都要重新走一遍上述流程。。。。

建议将OpenFeign 接口定义在消费端 A，B 只需要提供一个接口实现即可。所不好的地方无非是 XxxRequest、XxxResponse 类冗余了一份，但其实并没有什么问题，因为对于 Feign 来说请求和响应的 BO 类并不需要字段完全一致，它的解码器会智能的解析响应并封装到你的 XxxResponse 接收类中。

这个类 XxxRequest、XxxResponse 等，仅仅是 A 服务为了映射请求结果而本地自定义的一个映射数据结构，这个映射数据结构和 B 服务可以说是没关系的。所以当然应该放在 A 这里。

高内聚低耦合本质的意义，就是把和一个服务（组件，应用，包，等等等等）相关的代码全部包在一起，不要和外界有牵扯，你有牵扯就会引发修改时的依赖地狱。

### **12、写有意义的方法注释** ###

### **13、和前端交互的 DTO 对象命名** ###

什么 VO、BO、DTO、PO 我倒真是觉得没有那么大必要分那么详细，至少我们在和前端交互的时候类名要起的合适，不要直接用映射数据库的类返回给前端，这会返回很多不必要的信息，如果有敏感信息还要特殊处理。

推荐的做法是接受前端请求的类定义为 XxxRequest，响应的定义为 XxxResponse。以订单为例：接受保存更新订单信息的实体类可以定义为 OrderRequest，订单查询响应定义为 OrderResponse，订单的查询条件请求定义为 OrderQueryRequest。

### **14、不要跨服务循环访问数据库** ###

跨服务查询时，如果有批量数据查询的场景，直接写一个批量的 Feign 查询接口，不要像下面这样

list.foreach(id -> {
        
    
    	UserResponse user = userClient.findById(id);
    
    });

因为每一次 OpenFeign 的请求都是一个 Http 请求、一个数据库 IO 操作，还要经过各种框架内的拦截器、解码器等等，全都是损耗。

直接定义一个批量查询接口

@PostMapping(\"/user/batch-info\")
    List<UserResponse> batchInfo(@RequestBody List<Long> userIds);

这就结束了吗？并没有，如果遇到这种 userIds 的数量非常大，在 2000 以上，那么在实现方就不能在数据库中直接用 in() 去查询。在实现方要拆分这个 useIds 。有索引的情况下 in() 1000 个元素以下问题不大。

public List<XxxResponse> list(List<Long> userIds) {
        
    
      	List<List<Long>> partition = Lists.partition(userIds, 500); 
      	List<XxxResponse> list = new ArrayList<>();
      	partition.forEach(item -> list.addAll(xxxMapper.list(item)));
    	return list;
    
    }

### **15、尽量别让 IDEA 报警** ###

IDEA 代码窗口有警告就代表代码还可以优化，或者说存在问题。

### **16、尽可能使用新技术组件** ###