程序员遇到Bug时的30个反应

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现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开始出现时,你必须调试整个脚本来寻找解决方案。因此,要是有
一些有帮助的注释就会让你获益良多。

21.“20分钟前它还可以工作的……”

在构建程序时,可能最令人沮丧的部分就是,它从能工作到不能工作——而你没有更新代码的任何部分!我发誓这是真的。而且这是没有任何意义的事情——

也许是其他程序正在运行缓存版本?有很多次你更新了一丁点代码,却导致了整个程序崩溃出错,完全停止了工作。恢复到最近可工作的复制文件,然后从那里开始
一步步前进。

22.“只是忘记了一个分号,然而整个程序却因此而轰然倒下。”

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

23.“我不知道让别人来修复我的代码,得花多少钱?”

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

24.“快速浏览Hackers News可以提高我的工作效率。”

很多程序员最喜欢阅读的,有关于软件和创业公司等社会新闻的选择是Hackers
News头版。它有很多关于自由职业、时间管理、软件开发、以及创业发布和融资的大量信息。虽然HN可以通过自我教育让你感觉自己变得更有效率了,但同时
它也会浪费你的时间。每隔几小时去快速浏览下Hackers News也不是那么糟糕。

25.“这个API怎么没有文档?!”

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

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

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

27.“让它正常工作的最快解决办法是什么?”

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

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

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

29.“我应该更有条理并且去学习Git ……下周就去研究它。”

开源版本控制包Git在程序员中非常受欢迎。相对于其他的竞争对手,它提供了更容易的学习曲线,并且被许多在线代码仓库,如Github上和
Bitbucket使用。开发人员很容易拖延去学习Git的行动,因为它对于初学者而言显然是有难度的。但是一旦你知道了基本命令,那么Git就是小菜一
碟。而且它还能使调试版本控制更加清晰。

30.“算了,我还是从头再开始吧。”

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

作者:小峰

来源:51CTO

时间: 2024-09-18 06:42:31

程序员遇到Bug时的30个反应的相关文章

程序员遇到Bug后的30种常见反应

开发应用程序是件压力很大的事情,尤其是当编写完代码后,突然冒出个Bug,这真是让人百感交集.痛不欲生.那么,如何平心静气地解决每一个Bug,是每个程序员都要修炼的地方. 下面本文将分享程序员遇到Bug时,最常说的30句话,不知道你中枪了没? 1.我不知道该删掉还是重写. 2.在开始项目之前,我应该先在Github上找找有没有合适的框架 3.为什么这个脚本会需要这么多库? 4.在网上肯定能找到解决方案. 5.是否有此功能插件. 6.Web项目,不知道IE支不支持. 7.从逻辑上,这本身就不合乎逻辑

程序员写代码时应该反复问自己的10个问题

问题描述 你想成为一名优秀的程序员吗?那么,现在是时候放下<24小时学会xxx语言>超级骗子书,相反,你应当养成每天反问自己以下10个问题的习惯.你的代码中是否有一种模式存在?找寻模式中的可行与不可行将发现其中看似无关的想法或基本原则.要对工作达到深入的理解,你必须养成反问自己"是否有一种模式存在?"的习惯.它不仅仅适用于你的代码.是否有适应各类型商业变化的模式吗?是否有一种适用于技术发展的模式?你有没有看到同类型的错误如雨后春笋般冒出来?所谓理解就是要理解模式-以赛亚·伯

程序员听到bug后的N种表现

程序员的世界里,不止有代码,还有bug,bug,bug 当出现bug时,程序员们的反应是怎样的呢?

程序员写代码时的各种内心戏 ……

01.读大神写的代码的时候:这是什么----我X,太牛X了. 读刚来的程序员写的代码的时候:这是什么----我X,太傻X了. 02.读大神写的代码的时候 当读其他程序员写的代码的时候 03.当别人写的bug,让自己发现的时候: 我操这个大撒比写出这么个烂代码 幸亏有哥这样神一样的存在才发现 哥真是救世主 没有哥这个公司分分钟要倒闭. 当自己写的bug,被自己发现的时候: 卧槽,隐藏的很深啊! 哥就是犀利,自己开发自己测试, 看测试那帮撒逼什么也不会干,这么明显的bug都测不出来, 真是一群废物!

程序员写代码时应该反复问自己的 10 个问题

你想成为一名优秀的程序员吗? 那么,现在是时候放下<24小时学会xxx语言v8.3>超级骗子书,相反,你应当养成每天反问自己以下10个问题的习惯. 你的代码中是否有一种模式存在? 找寻模式中的可行与不可行将发现其中看似无关的想法或基本原则.要对工作达到深入的理解,你必须养成反问自己"是否有一种模式存在?"的习惯. 它不仅仅适用于你的代码.是否有适应各类型商业变化的模式吗?是否有一种适用于技术发展的模式?你有没有看到同类型的错误如雨后春笋般冒出来? 所谓理解就是要理解模式 -

光大证券程序员演示操作时敲下的一个键

昨日下午,证监会就光大证券异常交易事件召开了专场通气会,公布了调查结果和处罚决定.因异常事件发生之后.信披之前的卖空操作,这一事件被定性为内幕交易.光大证券被处以没收所有违法所得,以及5倍的罚款,罚没款总金额达到5.23亿元.徐浩明.杨赤忠.沈诗光.杨剑波等四人被处以警告,罚款60万元,并在证券市场和期货市场都被终身禁入. 在给出严厉罚单的同时,证监会开始对各个券商的量化投资进行排查,并试图在鼓励创新与加强风控间寻求一种平衡.除此之外,对现有交易制度的反思也因光大证券事件被摆上台面,证监会即将出

30 岁: 程序员心中永远的痛?

软件业有这样一个笑话,"说起编程,博士不如硕士,硕士不如本科生,本科生不如专科生,专科生不如高中生--"."三十而立",然而在中国程序员这个团体中,很多到了30岁,或者还没有到30岁的幵发者对以后的发展便感到了盲目. 笔者由于工作关系,曾经广泛接触我们的程序员.对于他们,笔者发现,"程序员30岁话题"包含的不仅仅是30岁以后做什么?它需要程序员.软件企业 甚至整个软件产业一起来回答:"我们的软件业发展需要怎样的职业化程序员?投身软件业的

程序员的常见“谎话”:对,这是一个已知 Bug

简评:面对程序员,特别是当你是以测试人员或者产品经理的身份面对程序员时,他们往往会在出现问题的时候找一些小借口,其实大家都是一样,最容易原谅的就是自己,程序员也是的,所以你下次如果和程序员同学沟通时听到下面的这些话一定不要拆穿他们咯,给点面子,让程序员生活更美好,笑哭ing. 00. 我以后再给代码写注释和文档.(绝对是最大的谎言) 01. 这只是个临时方案,不会用在实际版本中. 02. 搞定了!只剩一些小事要处理. 03. 那个简单,几天就搞定了. 04. TODO 05. 就改一行代码,不会

当一群程序员试图去做一个 Logo 时,闹剧发生了

2015年夏天,名为 WebAssembly 的开源编程语言的开发人员决定给该项目设计一个 Logo. 随后,开发者之一,JF Bastien 在 GitHub 上宣布开启一场 Logo 大赛. "请将你为 WebAssembly 设计的 Logo 回复给我们"他写道,"我们还没有决定要怎么去选择最终的 Logo ,但公布时间肯定会和[最简可行产品]发布的时间差不多". 这个时间还没有到,比赛还在进行中. 在刚开始,程序员们都很认真地提交提案,例如: 还有像这样: