程序员在普通人的印象里是一份严(ku)谨(bi)的职业，也是一个被搞怪吐槽乐此不疲的职业，程序员们面对复杂的代码敲打电脑时连眉头都不会皱一下，但是有一个词却是他们痛苦的根源，它就是Bug。
测试人员、开发人员、管理人员对 Bug 的不同反应
当程序员找 Bug 的时候
程序员调 Bug 的感觉，就是这样的一波未平，一波又起
开发人员在演示中如何隐藏 Bug
叫新手程序员帮忙改 Bug
牛 X 程序员和 Bug 之间的 PK
千万不要和程序员直接说有 Bug
程序员遇到 Bug 时的 14个反应
开发应用程序是一个非常有压力的工作。没有人是完美的，因此在这个行业中，代码中出现 Bug 是相当普遍的现象。
面对 Bug，一些程序员会生气，会沮丧，会心烦意乱，甚至会灰心丧气，而另一些程序员会依然保持冷静沉着。因此，如何处理修复 Bug 的过程也值得我们细细琢磨。
我想分享一些程序员修复他们的源代码时所经历的想法。我相信很多开发人员和软件工程师经历过这些艰辛，然后在事后一笑而过。以下你经历过哪些？
1.“我不知道是要删除还是要重写它”
回顾从前老的源代码，会有一种想要返工写成较大块集群的冲动和诱惑。丑陋的逻辑语句，还有冗长的语法，导致代码非常难以阅读！
但话又说回来，如果代码没有坏掉的话，那就不要去修复它。这种汹涌澎拜的斗争是我经常要面对的，而且显然会困扰许多软件开发人员。
2.“在互联网的某个地方一定已经有了解决方案。”
我面对棘手问题的第一反应是上网查。程序员会将他们遇到的问题通过帖子发布到论坛上，然后这个问题最终得到解决并归档。
谷歌搜索问题关键字的好帮手，可以指点你往正确的讨论方向走。不幸的是，有的时候却是因为手头没有特定问题的太多信息而找不着北。
3.“虽然网站可以工作，但我害怕 IE 浏览器。”
在 Internet Explorer 中渲染网页的历史充满了艰辛考验，是我们有目共睹或亲身体验过的。
从 5.5 版本升级到 IE9、IE10，总是需要争取到更高级浏览器的支持。Web 开发人员可能会害怕调试网页，因为在 IE6 中打开页面是一个渲染噩梦。值得庆幸的是，这样的日子正在慢慢成为过去。
4.“我用 30 分钟写函数，花 2 小时让它工作。”
这难道不像我们自己的编程故事吗？你正兴致勃勃地在构建着什么，但是突然之间，函数输出了一个致命的错误。
所以，现在你必须回过头去删除一些代码块，以找出错误发生的行号。当你终于找到罪魁祸首，并解决它时，虽然有种精疲力竭的感觉，但也满心安慰。
5.“花费大力气才找出问题的原因是缺少了右括号。”
调试是你必须要采取的步骤，进两步，退一步。盯着代码数个小时，以为函数名或变量作用域中有哪里搞错了，最后才发现是遗漏了一个括号，这滋味，酸爽得不要不要的。所有这些时间都因为一个小小的语法错误而浪费。
6.“是不是有人动过了我的源代码？”
这听起来有点妄想和偏执，但有时你会不由自主地怀疑，是不是有人在你补觉的时候，写过这个东西了。
回顾过去几周或几个月做的项目会让你的心不断地往下沉。有时候你会发现一些你已经不记得添加的东西——甚至这个项目你最近一周才刚刚浏览过！我为代码而疯狂，但你永远不会知道…
7.“我不知道这意味着什么。”
你能遇到的最坏情况是，你对你正在浏览的源代码完全不知道该怎么做。可能是你自己的项目，也可能是别人的项目，但问题的根源是相同的。
现在，你必须决定是否值得花更多的时间去搜索替代方案，或仔细检查脚本以了解它是如何工作的。
8.“哦，天哪，我以前为什么不写点注释呢？”
当涉及到比较基础的前端 HTML / CSS / JS 时，我们没有必要写注释。但更复杂的脚本和程序却需要一定形式的条理组织，当你在几个月后，甚至若干年之后需要再回过头来看的话。
有时你会忘记注释函数及其参数、输出格式，和其他的必要数据。这在一段时间之后无疑会导致混乱。而且，当 Bug 开始出现时，你必须调试整个脚本来寻找解决方案。因此，要是有一些有帮助的注释就会让你获益良多。
9.“20 分钟前它还可以工作的……”
在构建程序时，可能最令人沮丧的部分就是，它从能工作到不能工作——而你没有更新代码的任何部分！我发誓这是真的，而且这是没有任何意义的事情——也许是其他程序正在运行缓存版本？
有很多次你更新了一丁点代码，却导致了整个程序崩溃出错，完全停止了工作。恢复到最近可工作的复制文件，然后从那里开始一步步前进。
10.“只是忘记了一个分号，然而整个程序却因此而轰然倒下。”
几乎所有我使用的编程语言都需要结束符。虽然不是所有的语言都有，但在 C/C++ 中是很常见的。
忘记添加结束符，不过是一个很显然的错误！但是解析器不知道这一点，它会抛出一个致命错误。
于是，你不得不额外花 20 分钟去搜索技术故障，而原本只需要用 1 秒钟补上那个缺少的分号即可。嗯，这就是调试软件的乐趣。
11.“我不知道让别人来修复我的代码，得花多少钱？”
聘请另一个开发人员的点子是挺诱人的，但从财政上看显然没有那么可行。而且如果你不亲身体验的话，又怎么能从这些错误中学到东西呢？
当你在经历多次失败之后，终于理解了某个编程概念的时候，那感觉真是棒极了。尽管如此，我的脑海里依然时不时地有一种 “让别人来修复代码” 的冲动。
12.“我真希望我保存了那个数据库的备份副本……”
在编写和调试代码时，我不会想到要备份。然而，数据备份提供了允许我们回过头去修改的踏脚石。这在实时的服务器环境中尤为有用，因为有什么变化会立即执行。
以防万一，我们应该记得保存网站文件和数据库的本地副本！虽然这会是一个恼人的任务，但其恼人程度远远比不上重建损坏的 SQL 数据库。
13.“我敢打赌更新我的软件将解决这个问题。”
管理编程语言依赖和插件的团队并不需要经常发布版本。有时，在你从计算机传输文件到实时服务器的时候，更新 PHP / Ruby / Python / SQL 版本可以解决调试问题。
本地更新很少能够帮助修复源代码中的 Bug，除非你的版本已经过时得无可救药。所以，值得一试！
14.“算了，我还是从头再开始吧。”
有时候，在你绞尽脑汁花费数个小时之后，可能要做的只是将你的工作文件移动到归档目录（或删除它们），再从头开始就可以了。但是，考虑到先前已经耗费的时间，你很难下定这个决心。
当我一筹莫展时，我往往会选择从头开始，因为这样才有可能找到完成项目的正确道路。
为什么程序员发现不了自己的 Bug？
作为开发就和我们成人一样看到问题总是以自己的世界观来理解，导致理所当然的就这样就对了，而真正的真相就被隐藏了。
而儿童一般能够做对的原因是，老师有引导性的提示细心的重要性并且长期踩雷。这也是测试人员和开发人员的区别之一，现在知道为啥测试不是谁都能做的工作了吧，开发也为啥找不到 Bug 了吧。
当程序员面对 Bug 的时候，如何机智甩锅？
当你面对 Bug 时，切勿慌张，以下措施教你轻松应对 Bug 带来的困扰。
1.打死不承认，这代码不是我写的，将锅甩出去。
2.睁眼说瞎话，在我电脑上是正常的呀，超级无辜。
赚取同情分
3.对方使用了错误的打开方式。
一定是对方的打开方式不对，重新打开试试，我神马都不知道
4.痛斥产品经理一顿，自己偷偷改好，气势不能弱，立场要坚定，迅速进入角色，完全没有 Bug 这回事，我就是王道。
以上模式可任意切换使用，但最终都逃不了，自己背地里偷偷，改 Bug 的宿命。
“我自己是一名从事了5年前端的老程序员，辞职目前在做讲师，今年年初我花了一个月整理了一份最适合2018年学习的web前端干货，从最基础的HTML+CSS+JS到移动端HTML5到各种框架都有整理，送给每一位前端小伙伴，这里是小白聚集地，欢迎初学和进阶中的小伙伴。"
加QQ群：867726593 (招募中）