本篇文章为你整理了两点之间直线最短，你写的是代码，我写的是艺术（两点之间直线最短的笑话）的详细内容，包含有两点之间直线最短但不是最快你想到了什么 两点之间直线最短的笑话 两点之间直线最短还是线段最短? 两点之间直线最短是公理还是定理 两点之间直线最短，你写的是代码，我写的是艺术，希望能帮助你了解 两点之间直线最短，你写的是代码，我写的是艺术。
随着需求迭代，团队代码量逐渐增多，熵增崭露头角。临近月底，我打开部分程序，再做一次代码走查。
✅ 两点之间直线最短
我在做代码走查的时候，发现一个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服务类里封装一个方法，封装根据单号获取订单记录的操作，这样，各通道处理类调用这个方法，可有效规避类似漏洞。
以其中一个通道处理类的改动为例，见如下提交记录截图。
其实，单说系统操作回调处理这个应用场景，这种程序实现方式并不可取。怎么设计更合理呢？你先琢磨，我后续补充。
✅ 待续
当看到一些不好的代码时，会发现我还算优秀；当看到优秀的代码时，也才意识到持续学习的重要！--buguge
本文来自，转载请注明原文链接：https:///buguge/p/16824452.html
以上就是两点之间直线最短，你写的是代码，我写的是艺术（两点之间直线最短的笑话）的详细内容，想要了解更多 两点之间直线最短，你写的是代码，我写的是艺术的内容，请持续关注盛行IT软件开发工作室。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。