我们为什么会引起bug?

作者: koo叔 分类: 编码与修养 发布时间: 2018-01-03 23:15 编辑

     我们写程序,为什么总写出bug呢?有人说,没有bug程序员不就失业了吗!没有bug还要测试人员干啥!当然这只是玩笑话,但也侧面反应了bug和程序代码不能分割的关系,即使是一句非常简单的代码,也可能会在不同运行环境,不同编译条件等情况下产生bug,所以如果严谨的说一段程序没有bug,肯定要附加上某种条件,即在xx条件下,该段程序是没有bug的。
         虽然没有绝对的无bug程序,但是我们不能以此为理由,就认为程序员写出bug是天经地义,理所当然的。因为大部分bug都是沟通不到位,马虎大意,考虑不周等引起的,而非运行环境等客观因素导致。所以有必要分析一下bug产生的原因,以避免大部分bug的产生。以下是一些常见原因分析及对策:
        1)心流状态自作主张:程序员写代码有时会进入心流状态,这时候如果写到一段需求不清或逻辑矛盾时,往往会选择一个自己认为正确的逻辑写下去,或TODO一段注释,以防心流被打断,当然有些程序员也会立即去问产品策划,求证后继续写。
         2)心流状态被打断:程序员写代码正嗨时,忽然被别人打断或紧急处理一项其他任务,等再回来时,可能就会疏忽一些逻辑处理。
         3)马虎大意:写代码心不在焉,导致漏写,错写的发生。
         4)没有考虑边界情况:有些是需求边界文档中没有全部说明,而程序员又没考虑到。有些是程序角度的边界,如整型溢出,数组越界,属于数据类型没有选对。
         5)第三方库的bug:选择了不成熟的库,或不适应部署环境的库导致。
         以上几种情况中,马虎和沟通不到位都是可以尽量避免的,两者避免之后可以减少80%的bug,如何避免呢?我总结为二慢一快,即写代码前慢思考,写代码中快速实现,写代码后慢交付。
          首先,拿到一个需求时,先不要急于写代码,一定要把需求了解充分,把各种可能性想清楚,对需求中提到的,多质疑,对需求中未提到的多确认。需求想清楚后,在技术建模阶段,提炼出重点难点,考虑项目中是否有可复用的模块,重点难点有没有成熟的解决方案等,考虑清楚这些可以大概列出代码实现的先后顺序。
        然后,按分析好的需求和计划好的实现顺序开始码代码,这个阶段一定快速果断,切勿拖拉,一气呵成。中间如果不被打断那真是极好的。如此阶段拖拉或被打断时间很长,则一些思路就会连不上,要花费很多时间重新梳理,很容易遗忘一些情况,导致bug。
        最后,快速实现后,按需求把功能自己过一遍,查漏补缺,此阶段不用求快,有些程序员为了赶时间,快速交付,产生了bug,又回头修复,来回折腾,反而浪费了时间。还有些程序员写完就不管,交付测试,且不管代码写的好坏,这是一种不负责任的表现。
         以上马虎和沟通原因只要稍加注意,养成习惯,都能做的很好,其他情况的bug,有时是我们不可控的,那就遇到了分情况一一对应吧。
        关于bug,就先到此吧,希望bug能少些,工作更轻松些。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

你的email不会被公开。必填项已用*标注

更多阅读
标签云