随着需求迭代，团队代码量逐渐增多，熵增崭露头角。临近月底，我打开部分程序，再做一次代码走查。

 

? 两点之间直线最短

我在做代码走查的时候，发现一个service方法里有这么一段代码

    List<PlatOrder> platOrderList = platOrderService.selectByOrderIds(Lists.newArrayList(bankOrder.getOrderId()));
    if (CollectionUtils.isEmpty(platOrderList)) {
        throw BizException.build("服务商未落单");
    }

    paymentReq.setOrigTransNo(platOrderList.get(0).getMerOrderId());

 

先说一下PlatOrder对应的数据表plat_order，plat_order是平台付款订单表，orderId是平台订单号，字段上有唯一索引。
我看这段逻辑，直觉是为什么调用 PlatOrderService#selectByOrderIds 方法获取一个列表，然后再取第一个元素呢？ 绕这么一个弯儿干啥，殊不知两点之间直线最短。我赶紧翻一下 PlatOrderService 的方法列表。 发现果然有另一个方法 selectByOrderId 。那么，这里调用 selectByOrderId ，像下面这样，是不是更优雅？

    PlatOrder platOrder = platOrderService.selectByOrderId(bankOrder.getOrderId());
    Assert.notNull(platOrder, "服务商未落单");

    paymentReq.setOrigTransNo(platOrder.getMerOrderId());

 

 

? 世上无易事，用心求精进

PlatOrderService 是基于 plat_order表的CRUD操作的service接口类。先说一下plat_order表，plat_order是平台付款订单表，orderId是平台订单号，字段上有唯一索引。
我在做代码走查的时候，发现 PlatOrderService 里有这么一个方法

public interface PlatOrderService {
    
    /**
     * 根据订单流水号查询单条平台订单记录
     * @param orderId
     * @return
     */
    List<PlatOrder> selecPlatOrderByOrderId(String orderId);
}

 

为什么会有这么一个方法呢？据我分析：①是当事人不清楚orderId的作用；②当事人迷糊、马虎，未加思考未作了解就写出来的；③当事人参考其他service如法炮制、信手拈来；④年久失修。

我不能再容忍这样的方法继续被使用。
因此，改成这样：

public interface PlatOrderService {
    
    /**
     * 根据订单流水号查询单条平台订单记录
     * @param orderId
     * @return
     */
    default PlatOrder selectByOrderId(String orderId){
        List<PlatOrder> list = selecPlatOrderByOrderId(orderId);
        if (CollectionUtils.isNotEmpty(list)) return list.get(0);
        return null;
    }
    
    /**
     * 根据订单流水号查询单条平台订单记录
     * 不要再调用这个方法了，请使用{@link #selectByOrderId(String)}
     * @param orderId
     * @return
     */
    @Deprecated
    List<PlatOrder> selecPlatOrderByOrderId(String orderId);
}

 

某天深夜，我突然一想，我的正确姿势，应该是直接删掉这个方法，斩草要除根。上班后，立即行动。快刀斩乱麻，相关调用一并改掉。

public interface PlatOrderService {
    
    /**
     * 根据订单流水号查询单条平台订单记录
     * @param orderId
     * @return
     */
    PlatOrder selectByOrderId(String orderId);
}

 

? 使用封装，彻底斩草除根

在请求外部三方通道付款完成后，外部三方通道系统会主动回调我方接口。我方程序里对于每个三方通道，都有一个对应的通道处理类。

几天前系统交易量增大，系统处理能力明显下降。经排查，发现一个通道处理类里，在使用 mybatisplus 的 Wrapper 根据单号获取订单记录时，由于单号字段类型不匹配，导致单号上的索引失效，数据库在执行sql时走了全表扫描，进而产生蝴蝶效应，拖垮整个系统。

我们立即修复这段代码。我意识到，其他通道处理类也可能存在类似漏洞。果不其然。斩草要除根，痛快的方式，是在PO实体的CRUD服务类里封装一个方法，封装根据单号获取订单记录的操作，这样，各通道处理类调用这个方法，可有效规避类似漏洞。

以其中一个通道处理类的改动为例，见如下提交记录截图。

 

 

其实，单说系统操作回调处理这个应用场景，这种程序实现方式并不可取。怎么设计更合理呢？你先琢磨，我后续补充。

 

? 待续