让知识连接你我
投稿赚钱
当前位置: 首页 > 职场生活 > 为什么程序员总是发现不了自己的Bug?程序员:假装看不见!
  • 101
  • 微信分享

    扫一扫,在手机上查看

为什么程序员总是发现不了自己的Bug?程序员:假装看不见!

2019.09.11 10:00 234 浏览 举报

  程序猿在平常人的记忆里是一份严(ku)谨()的岗位,同样是一个被恶搞神吐槽忘乎所以的岗位,程序猿们应对繁杂的程序代码敲击电脑上时连双眉都不易皱一下下,可是还有一个词确是他们苦痛的缘由,它便是bug。

  技术人员、技术人员、技术人员对bug的差异反映 当程序猿找bug的情况下 程序猿调bug的记忆,便是如此的山穷水尽,很多 技术人员在讲解中怎样才能潜藏bug 叫萌新程序猿协助改bug 牛x程序猿和bug相互之间的pk 最好不要和程序猿直接说有bug 程序猿碰到bug时的13个反映 程序流程是一个特别有工作压力的工作。

  没有谁是极致的,为此在那些行业中,程序代码中冒出bug是非常普遍性的状况。

  ” 应对bug,某些程序猿会心情不好,会压抑,会心慌意乱,以至于会垂头丧气,而另某些程序猿会依旧始终保持理智镇定自若。

  为此,怎样才能正确处理修整bug的历程也适合我们仔细思量。

  我觉得分享某些程序猿修整他们的程序代码中应经厉的念头。

  我坚信很多技术人员和开发工程师经厉过那些艰苦,在过后不是很看重。

  下列你经厉过哪几个? 1.“我想知道是要删除依然要重写它” 回望过去老的程序代码,会出现一种要想返工编成过大块集群的欲望和引诱。

  可笑的思维,再有冗长的写法,致使程序代码特别很难阅读理解! 但话又说过来,假如程序代码都没有坏了的情况下,那么就不必去修整它。

  这类壮阔澎湃的抗争就是我时常要应对的,并且明显会苦恼很多软件技术人员。

  2.“为何那些脚本再次这样多库?”特别是在是某些相对比较通俗化的语言,如java和objective、c库的总数将会越来越出现异常凶狠。

  当搭建一个再次很多基的架构时,再次的库的总数就越来越不言而喻得多。

  程序代码

  即便是某些主要用于jascpt的软件,也会附加再次许多的文档。

  偶尔,这会令人感觉烦杂扰人--但起码是实用的! 3.“有木有那些功能性的软件?” 需不需要再次创造发明车轮?软件是增加其他程序流程或网站地址操作界面的先进资源。

  与此同时,因此更为技术人员出示了某些自定和与众不同的选择方式。

  如果确实都没有可以用软件的情况下,为何不自身搭建一个呢? 4.“尽管网站地址可以工作,但我不愿意ie手机浏览器。

  ” 在internetexplorer中突出网站页面的历史充斥着了艰苦磨练,是我们看在眼里或亲身体验过的。

  从5.5版本升级到ie9、ie10,经常再次争得到更高级手机浏览器的适用。

  web技术人员将会会担心调试网站页面,由于在ie6中打开界面是一个突出噩梦。

  值得庆幸的是,这样的日子正在慢慢成为过去。

  5.“对于逻辑表达式而言,这似乎并不怎么合乎逻辑。

  ” 对于if/else循环,for循环,while循环,do循环等等,都有逻辑表达式。

  当浏览示例代码时,我试图指出我的逻辑是如何工作的。

  not运算符和比较标记的数量又是如此之多。

  我经常回过头去更新我自己的逻辑以便于更好地适合未来的做法。

  插件

  6.“我用30分钟写函数,花2小时让它工作。

  ” 这难道不像我们自己的编程故事吗?你正兴致勃勃地在构建着什么,但是突然之间,函数输出了一个致命的错误。

  所以,现在你必须回过头去删除一些代码块,以找出错误发生的行号。

  当你终于找到罪魁祸首,并解决它时,虽然有种精疲力竭的感觉,但也满心安慰。

  7.“在阅读多篇博客文章之后,我意识到,我之前全都是错的。

  ” 我常常会一开始就根据自己的编程思想,一头扎进去研究,但是这可能会导致麻烦,如果事情不像原先设想地那样顺利的话。

  已经有很多次在我启动一个项目之后,陷入了困境,只好寻求博客和其他论文的支持。

  最后我发现我的整个方法实际上是错误的,而且从头来过更容易!如果我开始的时候能先做一番研究的话,从长远来说,反而节省时间。

  8.“花费大力气才找出问题的原因是缺少了右括号。

  ” 调试是你必须要采取的步骤,进两步,退一步。

  盯着代码数个小时,以为函数名或变量作用域中有哪里搞错了,最后才发现是遗漏了一个括号,这滋味,酸爽得不要不要的。

  所有这些时间都因为一个小小的语法错误而浪费。

  9.“喝杯咖啡,休息一下!” 有时候,你只是需要站起来,远离显示器。

  代码

  将鼠标悬停在键盘数个小时,反而有助于打破常规。

  大多数健康指导都会建议我们每隔30-60分钟休息一会。

  但是这一切都取决于你的需要,如果你觉得在程序中间休息更令人懊恼的话,那就不要中断。

  10.“我应该把这个项目束之高阁,以后再来处理它。

  ” 休息的另一个选择是离开你的项目,而不仅仅是远离你的电脑。

  如果还有其他工作需要做,那么不妨去做其他工作。

  相对于已经花费了5个小时来解决问题依然不得入门而言的话,这将能更好地分配时间和资源。

  11.“哦,天哪,我以前为什么不写点注释呢?” 当涉及到比较基的前端html/s/js时,我们没有必要写注释。

  但更复杂的脚本和程序却需要一定形式的条理组织,当你在几个月后,甚至若干年之后需要再回过头来看的话。

  有时你会忘记注释函数及其参数、输出格式,和其他的必要数据。

  这在一段时间之后无疑会导致混乱。

  而且,当bug开始出现时,你必须调试整个脚本来寻找解决方案。

  因此,要是有一些有帮助的注释就会让你获益良多。

  插件

  12.“20分钟前它还可以工作的……” 在构建程序时,可能最令人沮丧的部分就是,它从能工作到不能工作--而你没有更新代码的任何部分!我发誓这是真的,而且这是没有任何意义的事情--也许是其他程序正在运行缓存版本? 有很多次你更新了一丁点代码,却导致了整个程序崩溃出错,完全停止了工作。

  恢复到最近可工作的复制文件,从那里开始一步步前进。

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

  ” 有时候,在你绞尽脑汁花费数个小时之后,可能要做的只是将你的工作文件移动到归档目录(或删除它们),再从头开始就可以了。

  但是,考虑到先前已经耗费的时间,你很难下定这个决心。

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

  为什么程序员发现不了自己的bug? 作为就和我们一样看到问题总是以自己的世界观来理解,导致理所当然的就这样就对了,而真正的真相就被隐藏了。

  当程序员面对bug的时候,如何机智甩锅? 当你面对bug时,切勿慌张,以下措施教你轻松应对bug带来的困扰。

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

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

  赚取同情分 3.对方使用了错误的打开方式。

  一定是对方的打开方式不对,重新打开试试,我神马都不知道 4.痛斥产品经理一顿,自己偷偷改好,气势不能弱,立场要坚定,迅速进入角色,完全没有bug这回事,我就是王道。

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


本文首次发布于开创者素材 ,转载请注明出处,谢谢合作!

相关文章推荐