呵呵呵，提到了bug这件事我真的是哔了狗了。经常自以为写得天衣无缝的一段程序，就是运行出错，真是脑水都要气爆出来。而且有些bug它就是那么调皮。找你几天你都找不出来。（自己写的代码，自己真的太特么难找出bug了）这就是为什么公司要成立测试部门了。让别的人来找你的bug还靠谱点。anyway。

我会编程，但是我个人真的不喜欢编程。可是我有这么一哥们儿，编程就跟做爱一样，是有激情有快感的。但是，伴随着编码的快感，bug 总是如影随形，开发无止境，bug 随身行。对于他这样的人，我感谢bug。有点儿扯远了。总之关于bug真的是有很多话想说。

首先来看看遇到bug各种程序员是怎么反应的：

理性型：这个 bug 能复现吗？

自负型：这不可能，在我这是好好的。

经验型：不应该，以前怎么没问题？

幻想型：可能是数据有问题。

无辜型：我好几个星期都没碰这块代码了！

乐观型：只需要改一行代码，不会影响其它程序的。

实践型：你重启一下服务试试。

但是无论是哪一种程序员，遭遇 bug，内心都是崩溃的，头皮马上就发麻。特别是在公司里面：产品经理或测试人员在使用或测试产品的过程中抓到你的一个 bug 之后那种如获至宝的表情和欢呼声，绝对会让程序员的心久久不能平静！！扯了这么多，最重要的我们来聊聊bug可不可能不存在。答案肯定是hell no! 学过点儿测试的人都知道如果有道对错题问你测试的目的是找出程序中所有的bug。那么正确答案肯定是叉叉！

关于减少bug，觉得也是一些理论上的东西罢了。就我自己来说，没什么好的办法，只能下笨功夫，在编码之前尽可能把所有的可能性都想清楚，然后认真做好设计。每次自己程序出现的 bug 案例，记录到 bug 库里，检查代码的时候逐一对照，确保不会犯重复的错误。

小编推荐一个学C语言/C++的学习裙【 六六六，二九五，四九八  】邀请码凌云，无论你是大牛还是小白，是想转行还是想入行都可以来了解一起进步一起学习！裙内有开发工具，很多干货和技术资料分享！

下面是我整理的一份聊减少代码的内容：

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

另外，团队协作也很重要，前期的技术方案和设计评审、代码审查，对减少一些重大的错误和弱智的 bug 都非常有好处。与有经验的程序员一起评审一个技术方案，常常会发现一些重大的问题，比如为什么用缓存，为什么做持久化，高并发下怎么应对，这部分设计支持线程重入吗，这个循环为什么设置成10分钟，这个超时设置为什么是60秒，传输协议加密了吗，等等。

很多方案可能会仅限于解决当前的问题，但有经验的程序员却能透过时间的重重迷雾，发现这个方案在未来某个时间点可能爆发的问题。这就是评审的力量。国内很多团队的技术人员内心是抵触代码审查的，他们常常想，在这个国家我们已经被审查的够多了，就不要再自己审查自己了，然后很多 bug 就产生了。没有代码审查是不可思议的。在大公司的研发流程里，Code Review 是必不可少的一个环节，只有别人帮你做了 Code Review 并在代码上「打了戳」，你的代码才能进入 Code Base。在 Facebook，如果你 Review 了别人的代码，如果那个人休假了，你就要接手他的代码，出了任何问题都要唯你是问。

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

很多人在做代码审查之前会调研大量的代码审查工具，就像一个人在跑步之前，要先准备好跑鞋、袜子、压缩裤、压缩上衣、鼻贴、眼镜、口罩、导汗带、魔术头巾、各种手表、冷却喷雾、肌内效贴布……然后一个月过去了，你问他跑了几次，他会很扭捏的告诉你，髌骨带还没有到！没有工具一样可以做代码审查，你只需要偏转身体，在另一个程序员不忙的时候拍拍他的肩膀说，「来，看看我的代码，你能看懂吗？我准备把它们提交到代码库里」。然后阐述你的思路，倾听他的建议，并根据这次讨论的结果决定，是修改一下，还是继续提交到代码库。

不要小看这短短的20分钟，它可能会帮你避免的一些隐藏的和弱智的 bug。很多团队都是因为代码审查过程或工具过于复杂放弃了Code Review，典型的因噎废食，其实使用 less、diff 和 git 等工具，基本上就可以做一次完整的代码审查了。如果你过于依赖工具和过程，那说明你并没有抓住问题的核心。总的来说：重视团队协作，进行方案评审和代码审查。做到这两点，你会发现，代码中的 bug 会越来越少的。