程序员在普通人的印象里是一份严(ku)谨(bi)的职业，也是一个被搞怪吐槽乐此不疲的职业，程序员们面对复杂的代码敲打电脑时连眉头都不会皱一下，但是有一个词却是他们痛苦的根源，它就是Bug。
当程序员找 Bug 的时候
程序员调 Bug 的感觉，就是这样的一波未平，一波又起
开发人员在演示中如何隐藏 Bug
叫新手程序员帮忙改 Bug
牛 X 程序员和 Bug 之间的 PK
千万不要和程序员直接说有 Bug
面对 Bug，一些程序员会生气，会沮丧，会心烦意乱，甚至会灰心丧气，而另一些程序员会依然保持冷静沉着。因此，如何处理修复 Bug 的过程也值得我们细细琢磨。
我想分享一些程序员修复他们的源代码时所经历的想法。我相信很多开发人员和软件工程师经历过这些艰辛，然后在事后一笑而过。以下你经历过哪些？
1.“我不知道是要删除还是要重写它”
回顾从前老的源代码，会有一种想要返工写成较大块集群的冲动和诱惑。丑陋的逻辑语句，还有冗长的语法，导致代码非常难以阅读！
但话又说回来，如果代码没有坏掉的话，那就不要去修复它。这种汹涌澎拜的斗争是我经常要面对的，而且显然会困扰许多软件开发人员。
2.“为什么这个脚本需要这么多库？”
尤其是一些比较大众化的语言，如 Java 和 Objective-C，库的数量可能变得异常凶猛。当构建一个需要大量基础的框架时，所需的库的数量就变得显而易见得多。
3.“有没有这个功能的插件？”
为什么要重新发明轮子？插件是扩大任何程序或网站用户界面的伟大资源。此外，它们还为开发人员提供了一些自定义和独特的选项。万一真的没有可用插件的话，为什么不自己构建一个呢？
4.“虽然网站可以工作，但我害怕 IE 浏览器。”
从 5.5 版本升级到 IE9、IE10，总是需要争取到更高级浏览器的支持。Web 开发人员可能会害怕调试网页，因为在 IE6 中打开页面是一个渲染噩梦。值得庆幸的是，这样的日子正在慢慢成为过去。
5.“对于逻辑表达式而言，这似乎并不怎么合乎逻辑。”
对于 if / else 循环，for 循环，while 循环，do 循环等等，都有逻辑表达式。当浏览示例代码时，我试图指出我的逻辑是如何工作的。
6.“我用 30 分钟写函数，花 2 小时让它工作。”
这难道不像我们自己的编程故事吗？你正兴致勃勃地在构建着什么，但是突然之间，函数输出了一个致命的错误。
所以，现在你必须回过头去删除一些代码块，以找出错误发生的行号。当你终于找到罪魁祸首，并解决它时，虽然有种精疲力竭的感觉，但也满心安慰。
7.“在阅读多篇博客文章之后，我意识到，我之前全都是错的。”
我常常会一开始就根据自己的编程思想，一头扎进去研究，但是这可能会导致麻烦，如果事情不像原先设想地那样顺利的话。
最后我发现我的整个方法实际上是错误的，而且从头来过更容易！如果我开始的时候能先做一番研究的话，从长远来说，反而节省时间。
8.“花费大力气才找出问题的原因是缺少了右括号。”
调试是你必须要采取的步骤，进两步，退一步。盯着代码数个小时，以为函数名或变量作用域中有哪里搞错了，最后才发现是遗漏了一个括号，这滋味，酸爽得不要不要的。所有这些时间都因为一个小小的语法错误而浪费。
9.“喝杯咖啡，休息一下！”
有时候，你只是需要站起来，远离显示器。将鼠标悬停在键盘数个小时，反而有助于打破常规。大多数健康指导都会建议我们每隔 30-60 分钟休息一会。
但是这一切都取决于你的需要，如果你觉得在程序中间休息更令人懊恼的话，那就不要中断。
10.“我应该把这个项目束之高阁，以后再来处理它。”
休息的另一个选择是离开你的项目，而不仅仅是远离你的电脑。如果还有其他工作需要做，那么不妨去做其他工作。
相对于已经花费了 5 个小时来解决问题依然不得入门而言的话，这将能更好地分配时间和资源。
为什么程序员发现不了自己的 Bug？
作为开发就和我们成人一样看到问题总是以自己的世界观来理解，导致理所当然的就这样就对了，而真正的真相就被隐藏了。
当程序员面对 Bug 的时候，如何机智甩锅？
当你面对 Bug 时，切勿慌张，以下措施教你轻松应对 Bug 带来的困扰。
打死不承认，这代码不是我写的，将锅甩出去。
2.睁眼说瞎话，在我电脑上是正常的呀，超级无辜。
赚取同情分
3.对方使用了错误的打开方式。
一定是对方的打开方式不对，重新打开试试，我神马都不知道
4.痛斥产品经理一顿，自己偷偷改好，气势不能弱，立场要坚定，迅速进入角色，完全没有 Bug 这回事，我就是王道。
以上模式可任意切换使用，但最终都逃不了，自己背地里偷偷，改 Bug 的宿命。
