程序员的修炼-我们为什么会编写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(代码审计),这是一个最好的办法,当然需要耗费不少的人力,但是能最大的去降低缺陷和错误.

1 目前，我也组建了一个自学群，可以一起讨论研究前端的各个事宜，以及提高能力的方法，只要你想了解前端，精通前端，都欢迎你们加入我们的前端自学。
2 你可以找到志同道合的朋友，相互激励的学习伙伴，还能得到大神的经验分享，和加入项目实战的机会。这是我的WEB前端q裙。---851231348
3 整理了-套最新的前端基础教程，学习前端的这个过程当中我也收集了很多前端学习手册，面试题，开发工具，PDF文档书籍教程，可以直接分享给你们。

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

解决方案:
无

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

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

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

解决方案:

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

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

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

(四、)总结

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

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

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