这篇文章讲述了2022年上线的功能在新年微调配置后出现的bug，源于服务端对配置规则来源的判断逻辑。作者强调了规范开发、逻辑清晰的重要性，以防类似小问题在复杂工程中累积成大问题。
神奇的bug
一个2022年2月就上线运行的功能，顺畅跨年运行至2024年初，业务同学在元旦之际微调了配置，然后神奇的事情发生了！
先是业务反馈配置怎么没有生效，随即立马动手在preprod、test环境分别做验证，结果表象是pre环境复现异常情况、test环境正常运行。快速尝试找原因，先看了后端返回结果，擦！返回类型不对啊。
内心os推测：
1、客户端请求服务端时传参缺失？
2、服务端内包了逻辑，判断返回错误？
前端开发检查了自己的请求，没动过啊。只有简单的业务类型、请求站点，随即判断可能是后端内置了逻辑。接力棒给到服务端开发者，一顿review，没问题啊！
几分钟后，程序员恍然拍大腿......
原来配置里面有2个不同的来源（定义分别是FLOW_SYSTEM 、 SYSTEM），服务端的内置逻辑是检查配置规则是否包含这个SYSTEM来源的。对的，这里只是判断包含，没有要求包含且等于，所以当SYSTEM来判断的时候，它就理所当然的被FLOW_SYSTEM包含了，取值就取成了FLOW_SYSTEM。
为什么test和pre验证出来不同的结果，那是因为规则在数据库的顺序导致的，在前面被查询到的规则数据就会被返回给用户了。
我们说规范开发，不只是数据定义，虽然数据定义的规范性也可以避免这一类的问题，但这就要求每一个开发者需要有严格的自我要求和对业务的理解。为了降低这种问题发生的概率，我们更应该做的是从逻辑设计和构建上就做好区分，这里的逻辑构建不只是产品经理要去驱动的，主动提出来需要开发者关注的。同样也是开发者本身作为Owner需要具备的意识，从代码的可维护性上来说值得去提前考虑，从而面对业务多样的变化和维护人员的更替。
所以你看很多简单的东西，其实背后是一套逻辑模型在支撑，逻辑构建也自然成为重要的一环。可能你觉得这不就是一个小问题吗？可是这样的小问题，在一个复杂的工程里面，如果没有严密的逻辑模型，那将是遍地成孔，要知道 千里之堤 毁于蚁穴。这样的案例在现实工作和生活中要的太多了。好啦！希望每一个看到的朋友都能够在工作和生活中拥有这样的思考💭
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
