我想分享一些程序员在努力修复自己代码中的bug时的口头禅和主意.当事情变的紧张时,这些总会显的轻松幽默.一般情况下,应用也会正常运行,你也可以继续下一个工作任务.
我相信很多Web开发人员和软件工程师都会遇到这些问题,而且事后还在笑。
1.“我不知道是该删除还是重编写。”
回归历史源代码会诱使程序员重新产生更多的障碍集群。逻辑性差的冗余句法令人无法理解!然而，如果它没有中断，请不要去修复。这是我经常挣扎的问题，相信也困扰了不少其他软件开发员。
2.“我应该在开始架构时检查Github版本控制系统。”
绝大多数开发员都应该知道Github版本控制系统及每天公布的开源项目。涉足所有计算机语言的程序员，利用网络分解研究现有项目，进行维基论坛讨论或发表个人的代码报告。这些为很多项目的插件和模板提供了很多很好的资源。
3."为什么这个脚本需要如此多的库"
尤其是变得越来越重量级例如 java和Objective-C，库文件的数量日益增加。非常明显的是当建立一个框架时就需要许多的基础库。甚至一些JavaScript的插件都需要大量额外的文件。有的时候杂七杂八的东西很招人烦 -但至少它能运行。
4“在互联网上移动一定会有解决方法”
遇到困难问题我的第一反应是在互联网上查找。许多的程序员会把他们遇到的问题发布到论坛上，问题最终得到解决并保存下来。谷歌极好的挑选出你问题相关的关 键字并且为你指出了正确的导向，这些都为讨论提供了有益的线索。不幸的是，有的时候对于一个特定的问题还没有过多的信息。
5.“有这个功能的插件么？”
为什么要重造轮子？插件是扩展任何程序或网站用户界面的一个很好的资源。另外他们可以为开发者使用的一些定制的独特的选项。如果不存在已有插件的话，为什么不自己创建一个呢？
6.“网站项目，我害怕Internet Explorer。”
使用Internet Explorer渲染网页时遇到的坑我就不提了。从5.5版本到IE9-IE10浏览器支持方面的争议一直不断。Web开发人员可能害怕网页调试，使用IE6渲染更是噩梦。谢天谢地，那些日子已经慢慢成为了过去。
7.“逻辑语句——它本身就不是很有逻辑。”
现在有的逻辑语句有if/else循环、for循环、while循环、do循环……这个列表相当长。当查看一些旧示例代码时我尽力想弄明白我当时的使它运行的逻辑是什么。NOT操作的跳转数及比较符让人头晕。以后我会经常回过头来更新自己好的逻辑实践。
8.“我花30分钟写一个函数，却要花2小时让它工作。”
这不是十年前的故事吗？你沿着以前的套路轻松构建，突然函数输出了一个致命的error，因此你不得不回过头去清除代码块来试图找到故障的代码行。当你筋疲力尽最终找到了罪魁祸首后就像得到救赎一样。
9.“读了几个博客后我才意识到我之前的理解一直是错误的。”
我喜欢按自己的编程思想直奔主题，当事情没有按计划进行时这样做会导致麻烦。很多次我开始了一个项目后就陷入困境，然后便到博客或相关文章中寻求帮助。之后我发现整个方法实际上是错误的，重新开始会更容易!开始时多一点研究在长远看来是在节省时间。
10.“Stack Overflow上的好心人会帮助你。”
我已经数不清有多少次通过Stack Overflow解决困难的问题了。勇敢迈出第一步的话社区里有很多聪明的热心人愿意帮你。所有的在线论坛被定义为是软件开发者及前端/后端web工程师最全面的支持网。
11. “忘记关闭结束括号带来的麻烦”
你采取的所有步骤都是调试。向前两步，退回一步，或者向前更多。你会感觉花很多时间盯着代码，只为查找一些语法错误或者是变量的作用域，最终却只找到一个失踪的括号，这是一种奇怪的感觉。所有的时间都花费在了一个小小的语法错误上。在同一时间会感觉自己即是一个天才又是一个傻子。
12. “停下来，喝一杯咖啡”
有时候你需要的是起身离开显示器，在键盘上工作几个小时后。这有助于打破惯例。大多数的健康指南建议休息30-60分钟。但这一切都取决于你的需要，如果让你从编程过程中中断会使你苦恼，那最好还是不要中断。
13.“我应该把这个项目先放一放，稍后再处理它。”
工作间歇停顿的一种可选方式是远离你的项目，而不仅仅是你的电脑。也许存在另外一个需要你完成的工作，那么就过去把那项工作挑出来瞧一瞧吧。相比于你已经心迷神乱的死盯着要解决的另外一个问题而言，这也许是对时间和资源的一种更加好的分配方式。
14."我想古典音乐兴许能激发我的编程潜能"
有一种观点认为古典音乐能够在作物生命的早期阶段促进其生长。我个人则偏爱于古典音乐繁富的附注和错综复杂的音乐理论。爵士，钢琴，大型的乐队，优雅的音乐在世界各地的人文中都占有一席之地。那么在编程的时候听听轻妙的音乐会不会也能让你更精于调试之道呢？或许不会，但愿它不然让你更加的笨拙。
15.“也许现在正是验证Ballmer峰值理论的好时机”
我想很多读者都知道 Ballmer峰值，它由一个特殊的xkcd漫画创造而来。简而言之，这一理论表明程序员的编码能力会在消费了特定量的酒精之后达到一个顶峰。这源起于Steve Ballmer的古怪动作滑稽的像个酒鬼写出了随笔，尽管这有某些讽刺意味，因为Ballmer在微软从来都不是一个真正的程序员。试想我们将不得不等待另外一个人来为这一理论进行一次试运行。
16.“听起来像是妄想和偏执，但有时你只是猜想谁在你正忙着睡觉的时候挖了这个坑。”
遍览过去几周或者几个月的项目能够给你留下一种病态的感觉。有时候你将会发 现你这从来都不记得是自己留下的坑——尽管上个星期你都捣腾过这个项目!我发了疯似得把它写下来，但是你从来不知道...
17.“我不知道这意味着什么。”
你能遇到的最糟糕的情况就是看一看代码，完全不知道所以然。这可能来自于你自己的项目，也可能是其他什么人的项目，但都是同样的问题。现在你不得不去决定是否值得花更多的时间寻找替代方案，或者剖析代码以了解其工作原理。
18.“那段错误消息我需要查查Google才行”
多年PHP的工作经历过后，我不得不承认Google是我在调试问题时的最好伙伴。Objective-C、C++、
Java、Python和其他主流的语言的境况绝对都是相同的。错误消息尝试能对程序员有所帮助，但是除非你对不同的代码意味着什么牢记于心，否则它读起来则更加像是被翻译过的计算机语言。谢天谢天线上有那么多的帮助支持，而我们只需决定这些错误消息真正确切的意义。
19.“我应该停下来，把它放上一天...但是我真心想把它弄出来啊!”
我们都知道那种在你想要退出时极度沮丧的感觉，但只是感觉上像是放弃并不是正确的选择。你想要不断的推进，并在调试中尝试新的解决方案。但是如那最终证明是浪费了另外一个小时呢？我对这种境况并不陌生，它可是非常令人沮丧的。
20.“噢亲爱的，为啥我不写下任何注释呢？”
如果涉及到更加基础的HTML/CSS/JS时，并不常常是要留下注释的。但是更加复杂的脚本和程序则需要某些形式的组织结构，以便你在几个月之后，或者 甚至是十多年之后再来重温这些东西。有时候你会忘记对函数和它们的参数、输出形式和其它重要的数据加上注释。这无疑将会导致在bug开始出现而你不得不调 试整个脚本以找出解决方案的时候陷入迷途。那时候你就会抱怨如果仅仅有一些有用的注释该多好。
21.“这在20分钟之前还是起作用的呀...”
也许构造程序的时候最令人迷惑的部分就是当它变得有时运行又有时不能运行的时候——代码的任何部分都没有任何改动!我发誓这绝对发生过。而且它并没有任何 意义——也许其它程序正运行着一个缓存的版本？随后有一次只更新了一点点代码导致了整个程序由于错误而奔溃并且立即完全停止了工作。这时候就回滚到最近一 次的工作备份上来，并且从那里开始继续前进吧。
22.“你忘掉了一个糟糕的分号，整个程序就这样一下子崩掉了。”
我所用过的几乎每一种语言都需要一个符号作为一行的终止。它们并不都是这样的，但在C/C++家族中绝对是普遍如此的。当你忘记加上一个终止的分号时，它会是一个诚实的错误!但是解析器对此并不理解，而会抛出了一个致命的错误。现在你不得不为一个技术错误花另外20分钟挖掘代码，而它仅仅是一个分号的遗失。啊，这就是调试软件的乐趣。
23.“我在想花钱找人帮我修复这个问题得花费多少？”
铺天盖地的招聘额外开发者的想法是很诱人的，但很显然其可行性不及财务上的可行性。再加上如果不是你自己把手弄脏的，那你怎么从所有这些错误中学到教训？当你在许多次失败以后，最终理解了一个编程的概念时将会很有成就感。但这种思想并不总是能在我的脑海闪过。
24.“快速的浏览一下Hacker News一定能提高我的效率。”
许多程序员最喜爱的有关软件和初创公司的社会新闻是Hacker News 头版。它有许多关于自由职业者，时间管理，软件开发，还有启动发布会和资金筹集方面很棒的信息。尽管HN可以模拟出你自我教育而变得高效起来的感觉，它也是在消耗着你的时间的。每隔几个小时再去快速的重新扫扫新闻应该不会那么糟糕。
25. “这个 API 怎么能没有文档呢?!”
使用一个具有糟糕文档的插件或者框架时，最令人沮丧的事情是你不得不自己深入阅读源代码。我推崇的项目是，那些开发人员花时间特别设计出一个有用文档页的 项目。所有的参数与选项都被予以解释，可能甚至会在一些案例代码片段中使用出现。但是遗憾的是事实并不总是如此。最简单的办法就是远离文档贫乏的作业，以 免你自己陷入不幸。
26. “我当然希望我留下了那个数据库的一份拷贝…”
在编写代码并进行调试的时候，我总是想不起备份。然而，数据备份提供了一个垫脚石，使我们可以回到我们实施了某种更改之前的时刻。对一个生产环境的服务器 这个特别有用，在那个环境中变化总是在瞬间完成的。记住保留网站文件和数据库的本地拷贝，以备不时之需!这或许是很烦人的任务，但这也没有比重新创建一个 被破坏的SQL数据库更烦人。
27. “能让这个正常工作的最快的解决方案是什么?”
在东跌西撞的寻找了几小时的自定义解决方法后，很明显你需要一个新的方案了。程序员们都是希望功能正常运转之后，再去考虑接口设计的优雅问题。要确定最快最准确的解决方案，并应用它使之尽快的开始工作。然后，就可以放松心情去追求程序的美感了。
28. “我打赌，升级一下我的软件升级就能解决这个问题。”
那些管理着提供给编程语言使用的依赖包和插件的团队，不需要频繁的发布产品。有时升级你的PHP/Ruby/Python/SQL版本可能会解决一些调试问题，比如在从你的电脑向在线服务器上传文件的时候。除非你的版本实在是老的没治了，否则做本机升级很少能帮你解决代码中的bug。不过，还是值得一试!
29.“我应该学习并使用Git来组织代码……但下个周吧……。”
开源代码版本控制软件Git在程序员中非 常受欢迎。相比其他竞争对手它提供了一条更容易的学习曲线，它已经被应用在了许多在线仓库如GitHub和Bitbucket。开发者可能会改变主意因为 对初学者而言它有条稍陡峭的入门曲线。但是一旦你了解了基本的命令Git便是小菜一碟。它使得使用版本控制来进行调试更加条理清晰。
30.“放弃这个，从头开始。”
有时在尝试了长时间解决方案后，你需要把你的工作文件转移到归档目录(或删除)，然后从头开始。考虑到前一小时辛苦这确实是个艰难的决定。但当我谨记前车之鉴重新开始时这往往是项目走向完成所应该看到的。
