buguge - Keep it simple,stupid

知识就是力量,但更重要的,是运用知识的能力why buguge?

导航

两点之间直线最短,你写的是代码,我写的是艺术

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

 

✅ 两点之间直线最短

我在做代码走查的时候,发现一个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服务类里封装一个方法,封装根据单号获取订单记录的操作,这样,各通道处理类调用这个方法,可有效规避类似漏洞。

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

 

 

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

 

✅ 待续

 

posted on 2022-10-25 12:17  buguge  阅读(204)  评论(1编辑  收藏  举报