😂 IT段子

同事说他写的代码零 bug，我在 code review 里找到了三个空指针风险。我决定先把手上的事情做完再处理这件事。我把这个报错的堆栈从头读到尾，发现在最后一行有个提示。从此我多了一条团队规约

调试了两天的 bug，最后发现是少打了一个等号。我把复现步骤记了满满一页，下次再遇到至少能快一点。这条经验值直接拉满

bug 往往出现在你没改的那部分代码里。我在心里点了点头。我把这个问题的复现概率测了一下，大概百分之三。从此我多了一条团队规约

这个报错信息指向的位置和真正的错误隔了三层。我把它记在心里，没跟任何人说。我最后发现是一个大小写问题。我把这条经验写进了团队 wiki

bug 往往出现在你没改的那部分代码里。我想了想，觉得这话没法接。我把这两次运行的日志逐行 diff 了一遍，找到唯一的差异。果然现实比段子更精彩

复现不了的 bug 最消耗人，因为你连敌人是谁都不知道。我听完沉默了，因为太真实了。我在本地把环境完全对齐了一遍，还是复现不出来。连茶水间都安静了

我盯了半天，最后发现是拼写和大小写。我把整条链路在心里复盘了一遍。我把这个死循环的跳出条件补上了，进程终于不卡了。果然现实比段子更精彩

程序员的墨菲定律：演示的时候必出 bug，删掉的那段代码才是有用的。我忽然觉得，这可能就是这一行的常态。我把这个边界的输入手写了一遍，终于让它稳定复现

报错信息说问题在第 1024 行，那个文件一共 1023 行。我笑了笑，决定不解释。我发现是并发导致的，单线程下它一直是好的。幸好之前留了备份

这个 bug 的修复方案有两版，简单的那版风险更大。我笑了笑，决定不解释。我把日志的时间粒度从秒改成了毫秒，顺序终于排对了。连茶水间都安静了