IT：开发永无止境，Bug如影随形……我还就不信邪了？

　　来源｜极客时间《卖桃者说》

　　作者｜池建强

　　编辑｜成敏

　　你好，这里是卖桃者说。今天想跟你聊聊 Bug 这个程序员永远无法回避的话题。

　　每个热爱编程的人都在编写代码的过程中享受着创造的乐趣，但是，伴随着编程的快感，bug 总是如影随形，开发无止境，bug 随身行。bug 是每个程序员没法绕开的障碍，它们就在那里，修复一个，增加一个，似乎永不减少，永远存在。

　　不同的程序员在碰到 bug 时的反应不太一样，理性型的程序员会说，这个 bug 能复现吗？不能复现的不算 bug。自负型的会说，这不可能，在我这里明明是好的。经验型的会说，不应该呀，以前怎么没问题？幻想型的会说，可能是数据有问题。乐观型的会说，我只需要改一行代码就好，不会影响其它程序的。实践型的会说，重启试试。

　　无论你是哪种类型的程序员，遭遇 bug，内心都是崩溃的，尤其是产品经理或测试人员抓到你的一个 bug 之后那种如获至宝的表情和欢呼声，会让我们的心情久久不能平静。于情于理，防患于未然，减少编程中的 bug，对产品和程序员，都是最好的结果。

　　能不能一次编写出没有 bug 的程序呢？一般来说，并不能，除非你写一辈子 Hello World。我见过一些天才的程序员，他们差不多能做到这一点。接到任务之后，思考，冥想，在笔记本上画出数据结构或某个算法片段，腹稿打的差不多了就开始编程，用 Vim、Emacs 或 IDE 工具，大部分时候能够一气呵成，然后构建代码，构造测试数据，运行程序，在反复调试中修复几个编程过程中没有考虑到的问题，就可以提交到代码库了。

　　他们的代码交给测试和其他开发者，少有人能挑出 bug，因为他们对代码有敏锐的感觉，能够在别人忽略的地方发现代码的坏味道，并给出巧妙而优雅的解决方案，他们是天生的代码创造者。

　　大部分人都不是天才程序员，我也不是，但我在年轻时大量产出代码的时候，差不多也能做到类似的效果。没什么好的办法，只能下笨功夫。

　　我会在编码之前尽可能把所有的可能性都想清楚，然后认真做好设计。我常常在工作时间完成代码的编写，下班后带着笔记本回家逐行进行 Code Review，对着设计图检查是否处理了各种异常和边界条件，并先于测试人员对自己的代码进行白盒测试和黑盒测试。

　　另外，在编程方面我奉行不要在同一个地方摔倒两次的原则，每次自己程序出现的 bug 案例，我都会记录到 bug 库里，检查代码的时候逐一对照，确保不会犯重复的错误。

　　在这里推荐一下 Dash 这个软件，不仅提供了各种技术框架的 SDK 参考，还可以分门别类记录代码片段，实乃编程之利器啊。

　　可能年轻的时候自尊心比较强，我难以忍受自己的程序被别人找出 bug，于是偷偷花费了两倍的时间来保证代码的质量，以至于团队的人认为我一次就能编写出高质量的代码。现在看来，我当时是个错觉制造者。

　　所以，减少 bug 的第一步，是提升自己的程序素养，努力不给自己和别人找麻烦。

　　另外，团队协作也很重要，前期的技术方案和设计评审、代码审查，对减少一些重大的错误和弱智的 bug 都非常有好处。

　　与几个有经验的程序员一起评审一个技术方案，常常会发现一些重大的问题，比如为什么用缓存，为什么做持久化，高并发下怎么应对，这部分设计支持线程重入吗，为什么没做幂等操作？这个循环为什么设置成 10 分钟，这个超时设置为什么是 60 秒，传输协议加密了吗，等等。

　　很多方案可能会仅限于解决当前的问题，但有经验的程序员却能透过时间的重重迷雾，发现这个方案在未来某个时间点可能爆发的问题。这就是评审的力量。

　　技术方案和设计评审一般是先于代码的，开始编写代码了，Code Review（代码审查）就可以提上议事日程了。国内很多团队的技术人员内心是抵触代码审查的，他们常常想，我们已经被审查的够多了，就不要再自己审查自己了，然后很多 bug 就产生了。

　　我和 Google、Facebook、Twitter、Airbnb 的工程师讨论过 Code Review，他们觉得没有代码审查是不可思议的。在这些公司的研发流程里，Code Review 是必不可少的一个环节，只有别人帮你做了 Code Review 并在代码上“打了戳”，你的代码才能进入 Code Base。在 Facebook，如果你 Review 了别人的代码，如果那个人休假了，你就要接手他的代码，出了任何问题都要唯你是问。

　　事实上，Code Review 才是真正的白盒测试，没有经过代码审查，仅凭测试很难保证代码质量。测试通过了但没有经过代码审查的代码仍然会出各种问题，这样的案例比比皆是。只有当另外一个人读了你的代码，并且表明能看懂时，这些代码才真正有了鲜活的力量。代码审查的意义就是，在你的代码合进代码库之前，至少有一个人读过你的代码。

　　很多人在做代码审查之前会调研大量的代码审查工具，就像一个人在跑步之前，要先准备好跑鞋、运动服、运动耳机、魔术头巾、冷却喷雾、肌内效贴布……然后一个月过去了，你问他跑了几次，他会很扭捏的告诉你，髌骨带还没有到！

　　没有工具一样可以做代码审查，你只需要偏转身体，在另一个程序员不忙的时候拍拍他的肩膀说，“来，看看我的代码，你能看懂吗？我准备把它们提交到代码库里”。然后阐述你的思路，倾听他的建议，并根据这次讨论的结果决定是修改一下，还是继续提交到代码库。

　　不要小看这短短的 20 分钟，它可能会帮你避免一些隐藏的 bug。

　　很多团队都是因为代码审查过程或工具过于复杂放弃了 Code Review，典型的因噎废食，其实使用 less、diff 和 git 等工具，基本上就可以做一次完整的代码审查了。如果你过于依赖工具和过程，那说明你并没有抓住问题的核心。

　　写了这么多，如何减少编程中的 bug 呢？不难，也不容易。对内，努力提高自己的程序员素养，不去浪费自己和别人的时间。对外，重视团队协作，进行方案评审和代码审查。做到这两点，你会发现，代码中的 bug 会越来越少的。

　　没有 bug 的代码，才是好代码！

　　好，这个话题我们今天就先聊到这里，如果文章对你有价值，欢迎谈谈你的 bug 体验。

　　卖桃者说，明天见。

　　点击链接，阅读更多文章！