开发应用程序是一项压力很大的工作，人无完人，工作中遇到各种各样的问题是很正常的事，有些程序员会生气，沮丧，郁闷，甚至泄气，也有一些程序员则会比较淡定。如何进行修复的过程，是值得我们好好推敲的。

许多web开发人员和软件工程师在编程中都会遇到困难，而事后回想起来，还会觉得很好笑。

　　1、我不知道该删掉还是重写

　　回归曾经写的源代码，总有一种想要重新返工的冲动，逻辑性差，冗余代码多，让人难以理解。但是，如果功能没出现问题，千万不要去修改。这是我经常要面对的困扰，相信也困扰了其他不少的软件开发者。

　　2、一开始架构时就该查Github

　　相信绝大多数开发人员都知道Github，它上面每天都会发布的一些神奇的开源项目。所有语言的程序员都会利用网络，为已存在的项目创建分支，添加项目wiki描述，或者创建自己的代码库，这些都为各种各样的项目的插件和模板提供了很多丰富的资源。

　　3、为什么这个脚本要依赖这么多库

　　说到一些越来越被广泛使用的计算机语言，像Java和Objective-C，库文件的数量也不断增加。很明显可以看出，构建一个框架就需要许多的基础库，甚至一些Java的插件也需要很多大量的附加文件。有时候这些乱七八糟的东西会很让人心烦，但是至少它能运行。

　　4、网上一定有解决办法

　　遇到困难时，我的第一反应就是上网查资料，很多程序员会在论坛上发布他们的问题，最终这些问题都会被解决并存档。Google会很神奇地选择一些跟你的问题相关的关键字，你就能够轻而易举地得到一些对你有帮助的讨论信息。不幸的是，有时候对于一些特定的问题，相关的信息还不是很多。

　　5、有这个功能的插件吗

　　何必要多此一举插件是扩展任何程序或者网站用户接口的很好的资源。另外它们还为开发者提供了一些定制以及独特的选项。如果没有可用的插件，那你为什么不自己创建一个呢？

      6、对于网站项目，我好担心坑爹的InternetExplorer

　　使用IE渲染网页遇到的各种困难，我就不提了，从5。5版本到IE9-IE10，对于浏览器的支持问题的争议就一直不断。Web开发人员会很害怕网页调试，使用IE6进行渲染更是噩梦。，幸好那些日子已经慢慢成为历史了。

　　7、有些逻辑语句，并不符合逻辑

　　有一些逻辑语句，像if/else循环，for循环，while循环，do循环…等等，还有很多。在回顾一些源代码时，我总是尽力想弄明白我的逻辑是怎么回事。我经常会回头更新代码，让逻辑更清晰。

　　8、我花30分钟写个函数，运行它却要花2个小时

　　这不是十年前的一个有关编程的故事吗？当一切都在按照你所所期待的顺利进行着，突然某个函数输出了一个致命的错误，所以你不得不回头删除代码块，试图定位出错的代码行。尽管这会让你筋疲力尽，但是一旦找到错误的原因，问题解决之后，你又会立马感到浑身轻松。

　　9、读了几篇博客后，我才意识到我之前所做的全是错的

　　我总是喜欢根据自己的编程思想直入主题，但是如果事情没有按照我原本的计划进行时，会导致很多麻烦。有很多次，我在做项目时，途中都遇到了麻烦，最后只得查找博客和相关文章去寻求帮助。然后又发现我的整个方法完全错了，还不如从头开始更容易点。所以从长远来看，在项目开始时多做点研究反而会节省时间。

　　10、StackOverflow上有好心人或许能帮助我

　　我已经数不清有多少次，遇到问题都是通过StackOverflow得到解决的。只要你提出问题，社区里就会有很多聪明，友好的热心人愿意帮助你。所有的在线论坛里，它绝对是支持软件编程和前后端web开发的最全面的网站。

　　11、这个问题竟然就因为少了个右括号

　　调试是我们经常要用的方法，向前两步，回退一步，再向前两步，如此反复。为了查找函数命名或者变量作用域等错误，盯着代码看了数个小时，结果发现只是缺少了一个括号，你会有种哭笑不得的感觉。所有的时间都浪费在了一个小小的语法错误上，那一刻，你会觉得自己既是天才，又是傻子。

      12、喝杯咖啡，休息一下

　　有的时候你需要起身离开显示器，连续敲了几个小时的键盘，如果中间休息一下，会对你的身体有益。大多数健康指南都建议每30-60分钟休息一次。但是还是要取决于你的需要，如果你感觉中间暂停去休息会打断你的思维，让你很不爽，那就最好不要了。

　　13、我应该先把这个项目放一放，稍后在处理它

　　休息的另一种方式就会暂停你手中的项目，而不是离开你的电脑桌。或许你还有其他的工作要做，那就继续下一项任务。比起试图在一个花了5个小时还没解决的问题上继续挣扎，这会是一种更合理地分配时间和资源的方式。

　　14、我在想或许古典音乐能够激发我的编程潜能呢

　　有一种说法认为古典音乐能促进植物的早期生长，我个人更偏爱古典音乐错综复杂的注解和音乐理论。爵士，钢琴，大型乐队，优雅的音乐在全球各地的人类文化都占有一席之地。所以编程的时候听点美妙的音乐会让你调试起来更得心应手呢。当然也有可能，会让你更加心烦意乱。

　　15、或许现在是验证鲍尔默峰值理论的好时机

　　我相信很多读者都知道鲍尔默峰值，它是根据一个特殊的XKCD漫画得来的。简单来说，这个理论认为程序员的编码能力在喝了定量的酒后，会达到一个峰值。这个起源于SteveBallmer的些古怪滑稽的姿态被认为是像一个醉汉在说胡话。尽管这有点讽刺，因为鲍尔默在微软从来算不上一个真正的程序员，猜想我们只有等其他人来实践这个理论了。

　　16、是谁动了我的代码？

　　这个听起来有点像妄想症，但是有时候你很想知道是谁趁你补觉的时候写的这些东西。回顾过去几周或者几个月的项目，会给你一种晕乎乎的感觉。有时候你会不记得你写过这些东西—尽管上周你还在参与这个项目。好像是我很疯狂地写的代码，你却从来不知道…

　　17、完全不知道这是神马东东

　　你遇到的最糟糕的情况应该是在研究源代码时，完全不知道它是在干什么，可能是来自你自己的项目，也可能是其他人的项目，但是问题都一样。这个时候，你必须确定是否值得花费更多的时间去寻找其它解决方案或者仔细剖析代码，研究它到底是干什么的。

      18、直接google下错误提示

　　鉴于多年的PHP经验，我不得不说Google真的是调试问题的最好的小伙伴。这对于Objective-C，C++，Java和其他的主流语言的境况一定是相同的。错误提示信息对我们很有用，但是你必须记住不同的错误代码代表什么意思。它读起来更像是被翻译过的计算机语言。幸好有这么多在线支持，让我们确定这些错误信息代表的真正意思。

　　19、今天应该到此为止了，可我真的想把这个问题解决了

　　我们都知道想要退出时的那种极度沮丧的感觉，但是同时又觉得放弃不是正确的选择。你很想继续前进，找出新的解决方案来。但是如果到最后还是浪费了一个小时，那该怎么办？我对这种情况并不陌生，它会让人特别沮丧。

　　20、哦买糕的，为什么我都没写注释呢

　　如果涉及到最基本的前端代码HTML/CSS/JS时，并不需要总是写注释。但是如果是比较复杂的脚本和程序时，就需要写一些标准的注释以便你几个月，甚至几年后来重温这些代码。有时候你会忘记给函数，参数，输出格式以及其他重要的数据写注释，这无疑会导致发生bug时你不得不调试整个脚本去寻求解决方案，感到非常困惑，到那个时候你会觉得要是有一些有用的注释该多好啊。

　　21、这个20分钟之前还好好的呢

或许构建程序时最让人沮丧的是，明明刚才还好好的东西，没有改过任何代码，这会儿却运行不起来了。我发誓这种情况绝对有发生，而且它没有任何意义—也许其它程序运行的是缓存版本呢然后也有一些时候我们只更新了一丁点代码，结果整个程序都崩溃并且完全停止运行。那就会回退到最新的备份版本，从那儿继续吧。

　　22、忘了一个该死的分号，整个程序都崩了

几乎我用过的所有的编程语言都要求每行结束时都要有结束符，但并不是所有的语言都这样，不过C/C++系列语言绝对是这样。当你忘记添加分号结束符时，这是多明显的错误！但是解析器并不不理解，便抛出一个致命的错误。接下来就得再花费20分钟时间去研究代码，查找技术错误。最终发现只是少了一个分号。哈，这就是软件调试的乐趣。

      23、我想要招人来帮我修复bug，得花多少钱哪

　　雇佣程序员的想法听起来很诱人，但显然在经济上是不可行的。另外，如果你连自己的的错误都没解决，你又怎么能从这些错误中学到东西呢？经历多次失败，最后当你真正理解了编程的概念后，你会很有成就感。但有时候脑子里难免还是会闪过这种想法。

　　24、快速浏览下HackerNews，肯定能提高我的效率

　　很多程序员对于浏览软件和创业等社会新闻的偏爱选择都是HackerNews首页。它有大量的关于自由职业，时间管理，软件开发，创业发布和筹资资金等方面很棒的信息。尽管HN能够模拟出通过自我教育更加高效的感觉，但其实是在浪费你的时间。每隔几小时去快速浏览下新闻也没那么糟糕。

　　25、这个API怎么没有说明文档啊？

　　最让人沮丧的事情就是使用插件或者框架时，自带的文档很糟糕，你只好自己去深入阅读源代码。我更喜欢让开发人员花时间专门为项目设计一个文档页，对所有的参数和选项都给予解释，有可能的话，给出一些示例代码。但是很遗憾，这种情况几乎不可能。所以最简单的办法就是远离那些附带文档很糟的工作，以免给自己带来麻烦。

　　26、我真希望我已经对数据库进行备份了

　　在编写和调试代码的时候，我有时候会想不到备份。然而，数据备份能够帮助我们回退到做出某个特定的改变之前的版本，这对一个即时的服务器环境是特别有用的，有些变化瞬间就会发生。切记在本地保留对网站文件和数据库的拷贝，以备急需。你可能会觉得这样太麻烦了，但是总比你重建一个SQL数据库强多了。

　　27、怎样才能快速解决这个问题？

　　如果花费了数小时后，仍然未找到一个解决办法，很明显你需要一个新的方案了。程序员总是想要先实现功能，然后再去设计和美化界面。先确定一个最快的，最准确的解决方案，并尽力去实现和完成，然后再去考虑美化界面的问题就会很轻松了。

　　28、我敢打赌，你更新下我的代码，这个问题就解决了

　　那些为编程语言提供依赖包和插件的团队并不需要频繁地发布产品。有时候从本地传送文件到服务器的时候，更新PHP/Ruby/Python/SQL版本可能会解决一些调试问题。除非你的版本实在太旧了，否则本地更新很少能够帮助你修复源代码中的bug，不过还是值得一试！

      29、我真的该好好学习Git了，…还是下周吧

　　开源的版本控制控制软件Git在程序员中广受欢迎。跟其他竞争对手相比，它提供了一条更简单的学习曲线，被应用在了许多在线仓库像Github和Bitbucket中。可能对初学者来说，会有点难度，但是一旦你掌握了基本命令，你会发现使用GIt就是小菜一碟。它还让版本控制更加清晰。

　　30、算了，我还是从头开始吧

　　有时候尝试了数小时的解决方案后，你可能需要将你的工作文件归档(或者删掉它们)，重新开始。这个决定的最大难点就是你会考虑到前面数小时的工作会毫无收获。但是如果你保留之前的想法，项目却毫无进展时。重新开始，才有可能让项目顺利完成。