程序员的修炼-我们为什么会编写BUG

更新日期: 2020-07-01阅读: 2k标签: bug

在最近的一周,我维护的业务系统出现了很多坏毛病,一周七天crash掉了4次,每次都需要都是因为一点很小的问题,触发了蝴蝶效应,导致整个系统全盘崩溃,于是产生除了叙述本篇的想法,当然这并不是为了掩盖我在Coding上的一些细节处理和职责疏忽,只是为了从根本的细节上去分析这些问题。


(一、)为什么会产生BUG

首先我们需要尝试理解一下什么Bug?

关于bug的解释

bug 是指任何计算机程序或硬件系统中的错误,故障或缺陷。错误会产生意外结果或导致系统意外运行
简单来说:bug就是程序出了问题,产生了意外的结果,没有按照预期的结果去运行。

产生Bug的原因有很多种:

    开发者水平太低
   不同的编译及运行环境
   与需求方沟通不到位
   马虎大意、考虑不周
   放飞自我,Coding全靠自嗨
   选择了错误的或者运行不稳定的第三方库
以上原因总结,主观和客观因素都会影响到Bug的产生,正如误差不可避免一般,我们应该对自己写出的代码进行测试、分析、"沟通".


(二、)如何尽量避免Bug

鉴于以上bug产出的原因,我们可以通过这些一些对策来避免Bug的产生,下面是一些常见原因分析和处理对策。

1.开发者水平太低

在进行系统的构建中,部分开发者可能通常因为开发经验过少,或者语言不熟悉,会编写错误的代码,然后未经过代码测试和审计,便进行提交和上线操作,导致了异常的引发

解决方案:

如果是语法错误,可通过一些ide的代码检测器,或者语法检查来检测代码可否正常运行.
如果是php等弱类型语言,可使用静态代码扫描工具来发现程序中明显的语法错误.
编写足够的测试用例,覆盖整个模块的语句
请求你的伙伴进行CodeReview(代码审计),来改善代码的质量和发现代码中的缺陷
2.不同的编译及运行环境

因为业务的拓展和服务支持,需要部署多个不同的运行环境中,如:转账系统,你在测试环境中转账了1000元给用户小明,小明却在生产环境中收到了这1000元,并成功进行提现,往往因为没有环境判断,导致了失误的操作!

解决方案:

1.在代码中多进行注释说明,标明哪些函数会在其他环境中操作和运行

2.加强环境逻辑判断

以下是我在使用的一些标注和说明,其他开发者或我本人再次阅览该代码时,就会得到一个清晰的运行结果.

/**
* 执行该函数时,会根据env环境进行处理,详细如下
* prod(生产环境):会启动队列对视频进行转码、截图、写入到生产数据库中操作.
* staging(预演环境):不会启动队列,但会写入staging数据库中
* test(测试环境):会启动队列对视频进行转码、截图、写入到测试数据库中操作.
*/
$video = $this->uploadVideo($file);
$queue = $this->videoQueue($video);

3.与需求方沟通不到位

这是经常程序员与产品对撕的一个很重要原因,TA想要A,而你却做出了B,于是你们产生了很大的争论

解决方案:

多进行沟通,需求进行反复确认,不要上手就进行编码,先进行分析。
通过PM系统,留存需求规划与变更记录,以便每一次业务更改,都得能与系统中的问题对上号.
 4.马虎大意、考虑不周

编码时以为问题很小,修改代码,不走调试与测试流程,直接上线.

解决方案:

不要盲目过于自信,相信自己的主观判断,一定走测试流程,确保改动无误!(这是我之前经常犯的错,然后系统出了问题,我的fix commit从1变成了N....)
CodeReview(代码审计),这是一个最好的办法,当然需要耗费不少的人力,但是能最大的去降低缺陷和错误.

5.放飞自我,Coding全靠自嗨

解决方案:无

这类朋友不适合做开发者,适合去做创造者!

6.选择了错误的或者运行不稳定的第三方库

有时候为了省略接入时间,往往会忽略掉一些大型库,因为业务的支持只用到了一小部分,所以我们有时候会去选择一些mini库,最后由于不稳定或方案不成熟,出现错误的运行结果

解决方案:

如果业务级别比较高的话,不建议采用冷门或者无人问津的mini库使用,因为出现问题的损失会更大.
进行反复测试,开发人员对核心代码进行阅览,确保正常无误.
自我组织编写或实现,但是学习和开发成本比较高,小型规模不建议采取.


(三、)多与代码进行"沟通"

“橡皮鸭调试法”是我在阅读《编写可读代码》一书中看到的一个技巧,我在一个人开发的时候会使用这个技巧,我认为是一个不错的选择.

 

(四、)总结

我们为什么会编写BUG,如果没有BUG?开发和测试不就失业了吗?当然这只是一句玩笑话。
在此引用知乎上一句很有意思的话.

编码也亦如此,因为很多主观和客观的因素,导致程序执行了错误的逻辑,产生了不如预期的结果,作为一个合格的开发人员,我们应该尽力确保程序稳妥运行,减少失误和异常。

正如CZG提到的"你写的每一行代码,都是你的名片",我们每个人都义务去维护好这张名片,让其他人对这张名片充满敬畏之心,而不是"what shit code",诸君共勉!

来自:https://www.cnblogs.com/lyy-1/p/13207162.html

链接: https://www.fly63.com/article/detial/9378

10个JavaScript常见BUG及修复方法

JavaScript语言设计太灵活,用起来不免要多加小心掉进坑里面。如今网站几乎100%使用JavaScript。JavaScript看上去是一门十分简单的语言,然而事实并不如此。它有很多容易被弄错的细节,一不注意就导致BUG。

程序员修复一个bug的心路历程,太形象了

和你们一样,我也是一个普普通通的前端开发者,在日常工作中,大部分时间不是在写新代码,而是在改代码,或是需求被改了,或是报bug了。当别人想我们报一个bug,直到我们把bug完整的修复好,整个过程是一个怎样的经历?

程序员沉迷 Bug 可以有多疯?

苍天啊!大地啊!竟然有程序员,因为沉迷代码,快要痛失女友了!那么,程序员写起代码,究竟可以有多沉(shang)迷(yin)?程序员为了写代码,可以有多疯?看了网友们的评论

程序员遇到Bug时的多种反应 你是哪一种?

开发应用程序是一个非常有压力的工作。没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象。面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着

Bug的处理流程

缺陷的定义:软件没有实现产品的说明书所描述的功能、软件实现了产品说明书描述不应有的功能...缺陷的等级-致命:一招毙命的缺陷,使你的系统无法运行,有造成数据泄漏的安全性问题。严重:可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。

关于 injectBabelPlugin is not a function

在学习ant design的自定义主题这一功能时候,官方给到创建config-overrides.js文件,并且写入如下代码, 查阅资料发现react-scripts 升级到 2.1.2 以后破坏了 react-app-rewired,react-app-rewired的新版本删除所有方法injectBabelPlugin

零bug策略,会不会本身是个bug?

如今软件开发迭代频繁,随之而来的是产品质量难以保障,用户一天天被动找到 bug 而骂开发,开发要么被拉去祭天,要么拉慢开发新功能的进度条,分出时间精力处理 bug。这已经成了软件开发行业的一大难题,有什么解决方案呢?

不能精准定位bug?可能是你没get到这几个打印日志的诀窍!

当你遇到问题的时候,只能通过debug功能来确定问题,你应该考虑打日志,良好的系统,是可以通过日志进行问题定位的。当你碰到if…else 或者 switch这样的分支时,要在分支的首行打印日志,用来确定进入了哪个分支

Web开发人者的十大Bug跟踪工具

有许多可视化的 Bug 跟踪工具,通常可以根据特性集、集成和定价进行分类。选择一个 Bug 跟踪工具时,需要整体考虑团队的规模和需求。对于很多团队来说,项目管理并不是必需的,因此对 Bug 跟踪工具的真正需求变成了一个强大的解决方案提供者

程序员如何减少开发中的 Bug?

周会上同事抛出了一个问题,程序员如何减少开发中的 Bug?很有意思的一个话题,本篇文章我们来进行探讨与总结。爱因斯坦曾经说过:「如果给我一个小时解答一道决定我生死的问题,我会花55分钟来弄清楚这道题到底是在问什么

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!