程序员遇到Bug是家常便饭，遇到Bug的时候会有什么反应，也是程序员们为津津乐道的自黑话题。现在，有人在网络上分享了程序员遇到Bug的一些反应总结，一起来看看吧！
　　开发应用程序是一个非常有压力的工作。没有人是完美的，因此在这个行业中，代码中出现bug是相当普遍的现象。面对bug，一些程序员会生气，会沮丧，会心烦意乱，甚至会灰心丧气，而另一些程序员会依然保持冷静沉着。因此，如何处理修复bug的过程也值得我们细细琢磨。
　　我想分享一些程序员修复他们的源代码时所经历的想法。这是事情变得紧张时所触发的轻松幽默。通常说来，应用程序终将可以工作，然后你也可以进入到下一个伟大的任务。
　　我相信很多web开发人员和软件工程师经历过这些艰辛，然后在事后一笑而过。
　　1.“我不知道是要删除还是要重写它”
　　回顾从前老的源代码，会有一种想要返工写成较大块集群的冲动和诱惑。丑陋的逻辑语句，还有冗长的语法，导致代码非常难以阅读！但话又说回来，如果代码没有坏掉的话，那不要去修复它。这种汹涌澎拜的斗争是我经常要面对的，而且显然会困扰许多软件开发人员。
　　2.“对于起始框架我应该查看Github”
　　我想大多数开发人员都知道Github，上面每天都有数量惊人的开源项目发布。任何语言的程序员都可以通过互联网借鉴现有项目，加入维基讨论，或者创建自己的代码仓库。它是各种项目所需插件和模板的超棒资源。
　　3.“为什么这个脚本需要这么多库？”
　　尤其是一些比较大众化的语言，如Java和Objective-C，库的数量可能变得异常凶猛。当构建一个需要大量基础的框架时，所需的库的数量变得显而易见得多。即使是一些适用于JavaScript的插件，也会额外需要无数的文件。有时，这会让人觉得烦杂恼人——但至少是有用的！
　　4.“在互联网的某个地方一定已经有了解决方案。”
　　我面对棘手问题的第一反应是上网查。程序员会将他们遇到的问题通过帖子发布到论坛上，然后这个问题终得到解决并归档。谷歌搜索问题关键字的好帮手，可以指点你往正确的讨论方向走。不幸的是，有的时候却是因为手头没有特定问题的太多信息而找不着北。
　　5.“有没有这个功能的插件？”
　　为什么要重新发明轮子？插件是扩大任何程序或网站用户界面的伟大资源。此外，它们还为开发人员提供了一些自定义和独特的选项。万一真的没有可用插件的话，没什么不自己构建一个呢？
　　6.“虽然网站可以工作，但我害怕IE浏览器。”
　　在Internet Explorer中渲染网页的历史充满的艰辛考验，是我们有目共睹或亲身体验过的。从5.5版本升级到IE9-IE10，总是需要争取到更高级浏览器的支持。web开发人员可能会害怕调试网页，因为在IE6中打开页面是一个渲染噩梦。值得庆幸的是，这样的日子正在慢慢成为过去。
　　7.“对于逻辑表达式而言，这似乎并不怎么合乎逻辑。”
　　对于if / else循环，for循环，while循环，do循环等等，都有逻辑表达式。当浏览示例代码时，我试图指出我的逻辑是如何工作的。NOT运算符和比较标记的数量又是如此之多。我经常回过头去更新我自己的逻辑以便于更好地适合未来的做法。
　　8.“我用30分钟写函数，花2小时让它工作。”
　　这难道不像我们自己的编程故事吗？你正兴致勃勃地在构建着什么，但是突然之间，函数输出了一个致命的错误。所以，现在你必须回过头去删除一些代码块，以找出错误发生的行号。当你终于找到罪魁祸首，并解决它时，虽然有种精疲力竭的感觉，但也满心安慰。
　　9.“在阅读多篇博客文章之后，我意识到，我之前全都是错的。”
　　我常常会一开始根据自己的编程思想，一头扎进去研究，但是这可能会导致麻烦，如果事情不像原先设想地那样顺利的话。已经有很多次在我启动一个项目之后，陷入了困境，然后只好寻求博客和其他论文的支持。然后我发现我的整个方法实际上是错误的，而且从头来过更容易！如果我开始的时候能先做一番研究的话，从长远来说，反而节省时间。
　　10.“Stack Overflow上和善的人或许愿意帮助我。”
　　我已经数不清有多少次我通过Stack Overflow解决了难题。社区里都是和善和聪明的人，他们非常愿意提供帮助，如果你迈出第一步的话。在所有的在线论坛中，Stack Overflow是对软件编程以及前端/后端web开发支持广泛的网络。
　　11.“花费大力气才找出问题的原因是缺少了右括号。”
　　调试是你必须要采取的步骤。进两步，退一步。盯着代码数个小时，以为函数名或变量作用域中有哪里搞错了，后才发现是遗漏了一个括号，这滋味，酸爽得不要不要的。所有这些时间都因为一个小小的语法错误而浪费。
　　12.“喝杯咖啡，休息一下！”
　　有时候，你只是需要站起来，远离显示器。将鼠标悬停在键盘数个小时，反而有助于打破常规。大多数健康指导都会建议我们每隔30-60分钟休息一会。但是这一切都取决于你的需要，如果你觉得在程序中间休息更令人懊恼的话，那不要中断。
　　13.“我应该把这个项目束之高阁，以后再来处理它。”
　　休息的另一个选择是离开你的项目，而不仅仅是远离你的电脑。如果还有其他工作需要做，那么不妨去做其他工作。相对于已经花费了5个小时来解决问题依然不得入门而言的话，这将能更好地分配时间和资源。
　　14.“我很怀疑古典音乐能否激发我的编程能力。”
　　有一种说法是，古典音乐可以在生命的早期阶段促进植物生长。我个人非常喜欢在写复杂笔记时聆听古典音乐。爵士乐、钢琴、大乐团，优雅的音乐在全世界的人类文化中都有一席之地。那么，在编程的同时倾听智慧的音乐真的能够让你更智慧地调试吗？可能不会，不过希望它不会让你变得更笨拙。
　　15.“喝点酒吧，也许现在是检验鲍尔默峰值理论的好时机。”
　　很多读者都听说过鲍尔默的峰值理论，根据一个特殊XKCD漫画而得出。简单地说，这个理论认为程序员的编码能力在喝了一定量的酒之后，会达到一个峰值。作者名叫史蒂夫·鲍尔默，他的行为古怪，像是一个醉汉，这有一定的讽刺意味，因为鲍尔默在微软从来不是一名真正的程序员。也许我们需要等待别人来实践证明这个理论吧。
　　16.“是不是有人动过了我的源代码？”
　　这听起来有点妄想和偏执，但有时你会不由自主地怀疑，是不是有人在你补觉的时候，写过这个东西了。回顾过去几周或几个月做的项目会让你的心不断地往下沉。有时候你会发现一些你已经不记得添加的东西——甚至这个项目你近一周才刚刚浏览过！我为代码而疯狂，但你永远不会知道…
　　17.“我不知道这意味着什么。”
　　你能遇到的坏情况是，你对你正在浏览的源代码完全不知道该怎么做。可能是你自己的项目，也可能是别人的项目，但问题的根源是相同的。现在，你必须决定是否值得花更多的时间去搜索替代方案，或仔细检查脚本以了解它是如何工作的。
　　18.“我需要Google错误信息。”
　　在PHP中工作了多年之后，我不得不说，Google是我调试问题时的好的朋友。使用Objective-C、C ++、Java、Python和其他主要语言，也是如此。错误信息非常有帮助，但是除非你记得不同的代码意味着什么，否则它读起来更像是翻译过的计算机语言。值得庆幸的是，有很多在线支持可以帮助我们确定这些错误信息的真正含义。
　　19.“我应该停下来，收工……但我真的很想解决它！”
　　我们都有过极度灰心丧气，想要放弃的感受，但总感觉半途而废不是正确的选择。于是，你继续埋首钻研，并尝试新的解决方案来调试。但是，如果这还是意味着另一个小时的浪费呢？对于这样的情况我并不陌生，令人非常令人沮丧。
　　20.“哦，天哪，我以前为什么不写点注释呢？”
　　当涉及到比较基础的前端HTML / CSS / JS时，我们没有必要写注释。但更复杂的脚本和程序却需要一定形式的条理组织，当你在几个月后，甚至若干年之后需要再回过头来看的话。有时你会忘记注释函数及其参数、输出格式，和其他的必要数据。这在一段时间之后无疑会导致混乱，而且，当bug开始出现时，你必须调试整个脚本来寻找解决方案。因此，要是有一些有帮助的注释会让你获益良多。