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 Common Reactions Programmers Have When Things Go Wrong |