|
|
|
|
移动端

世界之谜:为什么程序员总是发现不了自己的Bug?

面对 Bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着。因此,如何处理修复 Bug 的过程也值得我们细细琢磨。

作者:佚名来源:51CTO技术栈|2017-12-11 09:27

程序员在普通人的印象里是一份严(ku)谨(bi)的职业,也是一个被搞怪吐槽乐此不疲的职业,程序员们面对复杂的代码敲打电脑时连眉头都不会皱一下,但是有一个词却是他们痛苦的根源,它就是Bug。

测试人员、开发人员、管理人员对 Bug 的不同反应

当程序员找 Bug 的时候

程序员调 Bug 的感觉,就是这样的一波未平,一波又起

开发人员在演示中如何隐藏 Bug

叫新手程序员帮忙改 Bug

牛 X 程序员和 Bug 之间的 PK

千万不要和程序员直接说有 Bug

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

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现 Bug 是相当普遍的现象。

面对 Bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着。因此,如何处理修复 Bug 的过程也值得我们细细琢磨。

我想分享一些程序员修复他们的源代码时所经历的想法。我相信很多开发人员和软件工程师经历过这些艰辛,然后在事后一笑而过。以下你经历过哪些?

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.“算了,我还是从头再开始吧。”

有时候,在你绞尽脑汁花费数个小时之后,可能要做的只是将你的工作文件移动到归档目录(或删除它们),再从头开始就可以了。但是,考虑到先前已经耗费的时间,你很难下定这个决心。

当我一筹莫展时,我往往会选择从头开始,因为这样才有可能找到完成项目的正确道路。

为什么程序员发现不了自己的 Bug?

最近在朋友圈流行了这样的一个小学数学题,当然结果是“出乎意料”,看似简单的结果,几乎很少有人做对,而分析下来的原因无非是惯性思维下的粗心导致的完全错误,今天小编就带大家一起分析下思考过程。

看图可知,猫=X 猫头=Y 猫爪=Z,既:

  • 3X=30
  • X+Y+Y=20
  • Y+Z+Z=9

所以得出 X=10 Y=5 Z=2,故结果:Y+Z+X=5+2+10=17。

一般大多数的第一结果可能都是这样!等等,注意最后一个应该是Y+Z×X=?

心中一百只草泥马奔过,再算一遍,Y+Z*X=5+2*10=25。

对不起还是错的,因为猫爪从 2 只。

变成了 1 只。

所以应该是Y+Z/2*X=?心中一千只草泥马奔过,再算一次:Y+Z/2*X=5+2/2*10=15。

对不起还是错的,因为最后一只猫少一个爪子,所以应该是:Y+Z/2*(X-Z/2)=?

心中一万只草泥马奔过,再算一次:Y+Z/2*(X-Z/2)=5+2/2*(10-2/2)=14。

其实大家会发现这个题目非常的“坑爹”,不就是故意折腾人么,但是在很多系统中,开发看到测试提出的 Bug 也是这样的感觉。

作为开发就和我们成人一样看到问题总是以自己的世界观来理解,导致理所当然的就这样就对了,而真正的真相就被隐藏了。

而儿童一般能够做对的原因是,老师有引导性的提示细心的重要性并且长期踩雷。这也是测试人员和开发人员的区别之一,现在知道为啥测试不是谁都能做的工作了吧,开发也为啥找不到 Bug 了吧。

当程序员面对 Bug 的时候,如何机智甩锅?

当你面对 Bug 时,切勿慌张,以下措施教你轻松应对 Bug 带来的困扰。

1.打死不承认,这代码不是我写的,将锅甩出去。

2.睁眼说瞎话,在我电脑上是正常的呀,超级无辜。

赚取同情分

3.对方使用了错误的打开方式。

一定是对方的打开方式不对,重新打开试试,我神马都不知道

4.痛斥产品经理一顿,自己偷偷改好,气势不能弱,立场要坚定,迅速进入角色,完全没有 Bug 这回事,我就是王道

以上模式可任意切换使用,但最终都逃不了,自己背地里偷偷,改 Bug 的宿命。

【编辑推荐】

  1. 如何在不会导致服务器宕机的情况下,用PHP读取大文件
  2. 关于企业的服务器硬件策略指南
  3. 无服务器计算不适合某些企业的三个警告信号
  4. CPU内核越多,虚拟服务器性能越强?
  5. 第二春,新拐点?服务器增长迎来新动
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月最赞

读 书 +更多

跨越网络工程师必备训练

本书是根据全国计算机技术与软件专业资格(水平)考试“网络工程师级考试大纲”编写的考试辅导用书。全书主体按考试大纲的章节编排,分上、...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊