今天你写bug了吗？

---

Bug程序员永远无法回避的话题

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

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

不同的程序员在碰到bug时的反应

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

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

能不能一次编写出没有bug的程序

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

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

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

如何编码减少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的代码，才是好代码！

总结

• 1.每个热爱编程的人都在编写代码的过程中享受着创造的乐趣，但是bug是每个程序员没法绕开的障碍，似乎永不减少，永远存在。

• 2.不同的程序员在碰到bug时的反应：
  理想型，bug能否复现；自负型，我这里明明是好的；经验型，以前没问题；幻想型，可能数据有问题；乐观型，只改一行代码就好。

• 3.防患于未然，减少编程中的bug，对产品和程序员，都是最好的结果。

• 4.能不能一次编写出没有bug的程序呢？一般来说，并不能。

• 5.如何编码避免bug

  • 1.所有的可能性都想清楚

  • 2.认真做好设计

  • 3.工作时间完成代码的编写，下班后带着笔记本回家逐行进行Code Review。

  • 4.对着设计图检查是否处理了各种异常和边界条件，并先于测试人员对自己的代码进行白盒测试和黑盒测试。

  • 5.记录到bug库，确保不会犯重复的错

  • 6.善于利用工具，如：Dash，编程利器

• 6.大公司的员工觉得没有代码审查是不可思议的。

• 7.代码审查的意义就是，在你的代码合进代码库之前，至少有一个人读过你的代码。

• 8.没有工具找同事也一样可以做代码审查

• 9.代码审查工具，less、diff和git等

• 10.对内，努力提高自己的程序员素养，不去浪费自己和别人的时间，对外，重视团队协作，进行方案评审和代码审查。

说明

• dash macOS 版本 https://kapeli.com/dash

• 本文参考自极客时间池建强老师的卖桃者说-第8期 | 今天你写bug了吗？