记一次差点被带偏的事例

本周其他同事值班时，接到线上反馈账单问题并排查出来是我写的一段代码抛异常了。

于是找我聊。我写的这段代码背景是当时应付账单往下游推结算时需要将账单明细文件的url也传递下去，当时我写了一个方法入参是账单号，出参是url，但是这个方法处理过程中回去查询账单文件表，如果查到多条记录就会抛出异常，现在线上反馈的问题正是这个异常导致。

一开始想让我改下代码，理由是我没有考虑找到多个文件时需要排序取最新一个的情况，乍一听很有道理的样子，顿时我也蒙了，我竟然漏考虑了这么常规的问题，但我内心其实仍然不太接受，因为这不是我的风格。

于是我私下仔细地把自己写的代码翻看一遍，尝试回想当时的思路。第一点：我当时将这个方法抽到service中作为公开方法，一定是我没找到现成可用的方法，而这又是一个公用的东西；第二点：站在这个方法定位上看，这个方法是对外提供根据账单号获取对应账单明细excel文件下载的URL的功能，若找不到代表还没生成文件此时返回null是正常的，若找到多个则一定是错误的，说明生成过程存在问题，因此抛出异常，至于为啥生成了多个，该问题在此处是不得而知的，也不应知道，因此这个方法不应承担对多个结果的筛查功能，如果这里画蛇添足做了筛查处理，那么系统中存在的问题将无法暴露出来。这么一梳理，豁然明朗，我这里抛异常是对的，就该这样，解决此问题的思路应是彻查为啥生成多个，如果允许生成多个那么也应当由生成的人来负责判定哪个是有效的。最后同事找到原因是账单V4之前有个漏洞导致生成多个，将那段时间的脏数据删除便解决了。

通过这个事情，再次映证写每个方法时细扣定位和职责虽然花时间但是是值得的，不少做也绝不多做，各司其职才能避免问题复杂化，这个案例生动的展示了低耦合的价值和意义。

标签：文件,一次,账单,多个,事例,生成,问题,差点,方法
来源： https://www.cnblogs.com/maimode/p/15912200.html