大猿来信(19)-你平常减少代码bug的方法是什么呢?

日期:2020-12-18 19:29:06

你好,这是大猿的第19封来信,这次我们谈谈bug。


“你又在写bug呢!”

 
不知什么时候,这句话就成了程序员之间调侃的话了。
 
 
虽然是句玩笑话,但听者大都觉得所言不偏离事实。的确,有代码的地方,就会有bug。也就说,我们的代码很难避免bug的出现,所以大都认同“又在写bug”的这个梗。
 
调侃归调侃,玩笑归玩笑,我们写代码不是为了写bug,而是为了完成功能。只是在完成功能代码的同时,bug也如影随形了。所以我们还要有一个小目标,就是消灭所有已知的bug,否者不予上线。
 
那么,问题来了,如何才能消灭bug呢?或者换句话说,如何最大限度的减少bug呢?我总结如下几个方面,仅供参考。
 
 
代码量
 
 
理论上来说,代码越少,bug也就越少。所以减少代码,是减少bug的有力手段。但是,不要望文生义,刻意减少bug,而是需要我们对业务代码进行进一步的抽象整合,提取共性的代码逻辑,该封装封装,该继承继承,让代码达到复用。
 
 
只要将封装的逻辑测试通过后,后面这段代码就可以被复用,很难再出错。如果不封装,每次都写一套,很难保证,每次都能写对,就算你去赋值原来的代码,也很难保证复制正确,写过代码的都知道,复制代码出错是常有的事儿。
 
 
 
简单的模型
 
 
 
逻辑越简单,出错的概率也会严重降低。我们在着手完成一项功能时,如果功能比较复杂,一定要把复杂的业务切分成一个个简单业务模型,简单的模型业务很难出错,那么多个简单的模型串起来,完成一个复杂的业务功能,总体上看,出错的概率会大大降低。
 
 
这里的关键点是业务的切分,以及切分之后如何将各个小模块串起来。这是个艺术活,需要一点思考,一点设计,一点经验,一点品味。比如,不少单位要求方法的行数不能超过80行,这都是在刻意要求程序员不要把方法写复杂了。
 
 
 
代码审核
 
 
 
好的团队,都会有代码审核机制。比如review代码,做代码的评审,都是减少bug的利器,若团队没有review代码的习惯,怎么办呢?
 
 
其实,自己写完代码后,完全可以拉着你旁边的同事帮你review,我一般称之为大家来找茬,毕竟一个人视角和思考角度是有限的,换个人过来,也许会从不同的角度来审视你的代码,极有可能会发现隐藏其中的bug,这也是比较常用的手段,效果显著。
 
 
 
代码工具
 
 
除了人工检查代码外,还有不少工具可以帮助我们大批量的检查代码。比如findbugs,checkstyle,PMD,还有阿里出的代码规约也有相应的插件可供使用。使用这些工具可以减少一些低级的,不易发现的小bug。
 
 
善用这些工具,也是我们必备的技能。但,工具只是工具,关键还在于自己的代码能力,好的工程师,代码写出来就是好的,漂亮的,工具都不配检查大师的代码。
 
 
这些都是降低bug的有效手段,但实施起来并不简单,比如找同事帮你review代码,可能同事会推脱说没时间,忙着呢;也可能对你爱答不理的,应付你;做起来,就知道很多阻力。那么,如果遇到了这种情况,要么妥协,要么就设法改变,去影响他人,再不行就换个更好的坑位。
 
 
祝冬安。