我编写软件已经有很长一段时间了。时间长到足以让我发布过人们不再使用的编程语言编写的程序，也长到足以让我把书中记载的几乎所有错误都至少犯过一次。你可能会认为，到现在为止，那些简单的错误应该早已成为过去式。
事实并非如此。这是一个关于其中某个错误的故事——写这篇文章主要是给那些认为危险错误都是复杂错误的初级开发人员看的。
它们并不是。让我来解释一下。
发生了什么
有一个流程极少有人使用，但每笔交易都涉及巨额资金，它悄悄地停止让用户完成操作。没有崩溃。没有警报。没有堆栈跟踪信息请求关注。只是一个验证检查冷静而自信地拒绝让用户完成操作。
原因：日期比较将当前月份视为未来时间。一个完全有效的输入被判定为不可能而被拒绝。另一端的用户没有做任何错事——代码只是简单地认定“现在”尚未到来。
低流量，高价值。这种组合至关重要。当数百万人访问一个损坏的页面时，你会在几分钟内发现问题。当只有少数人访问时——但每个人都代表着真金白银的损失——故障更加隐蔽，而每次故障的成本却巨大无比。这类问题不会触发你的仪表盘警报，但绝对会摆到某人的办公桌上。
这里是我必须承认的部分：我没有发现它。是一位用户发现的。他们是撞上南墙的人，弄清楚了出了问题，并报告了它。我的测试全部通过。我的仪表盘平静无波。我几十年的直觉没有标记出任何问题。故障之所以浮出水面，是因为外部有人遇到了它，并且费心告诉了我们。
一旦问题摆在我面前，诊断很快，修复只花了几分钟。但我想诚实地谈谈当时的感受：并不 triumphant（胜利）。这个错误是日期逻辑中的差一错误，这种错误我曾发誓早已远离——然而直到用户指出之前，我从未发现它。
我希望初级开发人员听到的部分
在职业生涯初期，你会假设大问题有大原因。如果重要的东西坏了，解释必须相应地复杂——竞态条件、微妙的架构缺陷，某种与损害相称的东西。
我在这里，带着几十年的经验告诉你，那是一个令人安慰的谎言。
软件评分不按曲线分布。一行日期的错误和一千行设计的失败可能产生相同的结果：一个人被阻挡，资金停滞，且不知为何。用户永远看不到原因是优雅还是尴尬。他们只看到一扇打不开的门。
在我的职业生涯中，给我以及我所效力的公司造成最大损失的错误，几乎从来都不是那些巧妙的错误。巧妙的错误会受到关注。它们会经过设计审查、仔细测试，经过三双眼睛的检查。简单的错误恰恰因为看起来太琐碎而不可能出错，从而溜了过去。没有人会像审查可怕的并发代码那样去审查日期检查。这正是日期检查咬人一口的原因。
我会对年轻时的自己说的话
- 日期是一个永远不会停止陷阱属性的陷阱。 时区、月份边界、“今天”、包含与排除范围、边缘处的差一错误。我有几十年的经验，但日期逻辑仍然需要我全神贯注。对待每一次比较都要像它隐藏着边缘情况一样，因为它确实如此。
- 低流量不等于低风险。 不要根据有多少人遇到错误来衡量其严重性。要根据每次遭遇的成本来衡量。保护宝贵资源的罕见使用路径比保护琐碎资源的繁忙路径值得更多的关注。
-
无聊的错误是 t
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
