花费大力气才找出问题的原因是缺少了右括号。

调试是每个人必须要采取的步骤。进两步，退一步。盯着代码数个小时，以为函数名或变量作用域中有哪里搞错了，最后才发现是遗漏了一个括号，这滋味，酸爽得不要不要的。所有这些时间都因为一个小小的语法错误而浪费。

喝杯咖啡，休息一下！

有些人在遇到棘手问题时，会远离显示器。将鼠标悬停在键盘数个小时，反而有助于打破常规。大多数健康指导都会建议我们每隔 30-60 分钟休息一会。但是这一切都取决于你的需要，如果你觉得在程序中间休息更令人懊恼的话，那就不要中断。

我应该把这个项目束之高阁，以后再来处理它。

休息的另一个选择是离开你的项目，而不仅仅是远离你的电脑。如果还有其他工作需要做，那么不妨去做其他工作。相对于已经花费了 5 个小时来解决问题依然不得入门而言的话，这将能更好地分配时间和资源。

我很怀疑古典音乐能否激发我的编程能力。

有一种说法是，古典音乐可以在生命的早期阶段促进植物生长。有人非常喜欢在写复杂笔记时聆听古典音乐。爵士乐、钢琴、大乐团，优雅的音乐在全世界的人类文化中都有一席之地。那么，在编程的同时倾听智慧的音乐真的能够让你更智慧地调试吗？大概会这样。

是不是有人动过了我的源代码？

这听起来有点妄想和偏执，但有时你会不由自主地怀疑，是不是有人在你补觉的时候，写过这个东西了。回顾过去几周或几个月做的项目会让你的心不断地往下沉。有时候你会发现一些你已经不记得添加的东西——甚至这个项目你最近一周才刚刚浏览过！为代码而疯狂，但你永远不会知道…

我不知道这意味着什么。

你能遇到的最坏情况是，你对你正在浏览的源代码完全不知道该怎么做。可能是你自己的项目，也可能是别人的项目，但问题的根源是相同的。现在，你必须决定是否值得花更多的时间去搜索替代方案，或仔细检查脚本以了解它是如何工作的。

我需要 Google 错误信息。

Google 是技术人员调试问题时的好朋友。使用 Objective-C、C ++、Java、Python 和其他主要语言，也是如此。错误信息非常有帮助，但是除非你记得不同的代码意味着什么，否则它读起来更像是翻译过的计算机语言。值得庆幸的是，有很多在线支持可以帮助我们确定这些错误信息的真正含义。

我应该停下来，收工……但我真的很想解决它！

我们都有过极度灰心丧气，想要放弃的感受，但总感觉半途而废不是正确的选择。于是，你继续埋首钻研，并尝试新的解决方案来调试。但是，如果这还是意味着另一个小时的浪费呢？对于这样的情况大多数人也许并不陌生，令人非常令人沮丧。

哦，天哪，我以前为什么不写点注释呢？

当涉及到比较基础的前端 html / css / JS 时，我们没有必要写注释。但更复杂的脚本和程序却需要一定形式的条理组织，当你在几个月后，甚至若干年之后需要再回过头来看的话。有时你会忘记注释函数及其参数、输出格式，和其他的必要数据。这在一段时间之后无疑会导致混乱，而且，当 bug 开始出现时，你必须调试整个脚本来寻找解决方案。

20 分钟前它还可以工作的……

在构建程序时，可能最令人沮丧的部分就是，它从能工作到不能工作——而你没有更新代码的任何部分！而且这是没有任何意义的事情——也许是其他程序正在运行缓存版本？有很多次你更新了一丁点代码，却导致了整个程序崩溃出错，完全停止了工作。恢复到最近可工作的复制文件，然后从那里开始一步步前进。

只是忘记了一个分号，然而整个程序却因此而轰然倒下。

虽然不是所有的语言都有，但在C/C ++ 中是很常见的。忘记添加结束符，不过是一个很显然的错误！但是解析器不知道这一点，它会抛出一个致命错误。于是，你不得不额外花 20 分钟去搜索技术故障，而原本只需要用 1 秒钟补上那个缺少的分号即可。嗯，这就是调试软件的乐趣。

我不知道让别人来修复我的代码，得花多少钱？

聘请另一个开发人员的点子是挺诱人的，但从预算和教学成本上看显然没有那么可行。而且如果你不亲身体验的话，又怎么能从这些错误中学到东西呢？当你在经历多次失败之后，终于理解了某个编程概念的时候，那感觉真是棒极了。尽管如此，很多人的脑海里依然时不时地有一种“让别人来修复代码”的冲头。

这个 api 怎么没有文档？！

在使用带有坏文档的插件或框架时，最令人沮丧的是，你必须靠自己去深入钻研源代码。开发人员花时间去专门设计可用文档页面的项目，所有的参数和选项都解释得清清楚楚，甚至可能会被用在一些示例代码片段中。但可悲的是，事实并非总是如此。所以最简单的方法是远离不良文档，不自找麻烦。

我真希望我保存了那个数据库的备份副本……

在编写和调试代码时，也许不会想到要备份。然而，数据备份提供了允许我们回过头去修改的踏脚石。这在实时的服务器环境中尤为有用，因为有什么变化会立即执行。以防万一，我们应该记得保存网站文件和数据库的本地副本！虽然这会是一个恼人的任务，但其恼人程度远远比不上重建损坏的 SQL 数据库。

让它正常工作的最快解决办法是什么？

在花费数个小时苦苦思考自定义的解决方案之后，很明显你需要一种新的方法。在设计漂亮的界面之前，程序员率先想到的是让功能正常工作。确定最快、最准确的解决方案，并实施这个解决方案让其工作才是 100％ 利用了时间。然后，再转移到漂亮美观方面。

我敢打赌更新我的软件将解决这个问题。

管理编程语言依赖和插件的团队并不需要经常发布版本。有时，在你从计算机传输文件到实时服务器的时候，更新 php /Ruby/ Python / SQL 版本可以解决调试问题。本地更新很少能够帮助修复源代码中的 bug，除非你的版本已经过时得无可救药。所以，值得一试！

算了，我还是从头再开始吧。

有时候，在你绞尽脑汁花费数个小时之后，可能要做的只是将你的工作文件移动到归档目录（或删除它们），再从头开始就可以了。但是，考虑到先前已经耗费的时间，你很难下定这个决心。但是，当我一筹莫展时，我往往会选择从头开始，因为这样才有可能找到完成项目的正确道路。