程序员是行走的bug机器? | 掘金年度征文

98 阅读5分钟

2020年终于要过去了,从以前的bug王到现在的平均每个需求平均2个bug的我,在过去的一年里,多了些思考,少了些焦虑,终于找到了减少bug的部分秘籍…..

文章可能有点干涩和枯燥,但是干货满满,都是一年来的真心话总结!

这里怎么有bug?为什么老是有bug?

作为程序员经常性的会听到来自各方的“bug, 灵魂拷问”,但是请相信,我们比任何人都不希望有bug!

现在的网络客服分为售前和售后,售前负责收集用户需求促成下单,售后负责产品卖出后的维系。但即便这样售后的保障也是有日期的,退货也只能在7天之内进行,你如果想保修更是需要交费续保。而程序员呢,是售前+售后,既要保障产品的需求被准确的理解并且实现,又要保障自己的产品售后没有问题,这个售后包含自己任职期的任何时间,甚至离职后的人文服务,起码出自我手的代码我会终生保修。

你看一个需求的终生,从产出到落地都是有着程序员的身影,程序员是实现需求的重要的一环。那么bug是怎样产生的呢?

需求理解偏差:这是最容易出现的也是最常见的bug产生原因。产品的诉求是A,我们可能理解成了B。还有一种需求的偏差可能是由于程序员的思维,程序员天然的在需求期会想到实现的问题,而程序员不仅会想到怎么实现还要想到其他的问题,比如这样做苹果审核会不会过?这样做交互是友好的么?实现代价大小的问题,受各种因素的影响,对产品的诉求A可能会在是现实产生偏差。这也是频发的Android和iOS为什么在部分实现上会不一样,因为2端程序员的思维是根据各端的特性来设定的,所以会存在一定的偏差,各自用了系统的特性。这也就是程序员充分理解需求背景的重要性。

隐藏功能的偏差:产品提了一个需求说我要打开一个活动的H5页面。但是后来做活动的时候发现不能成功跳转。程序员和测试当时曾经反复测试功能,是可以的,再次沟通下了解到,这次的打开是从外部链接直接打开App内的H5页面!而当时的程序员、测试普遍可能理解的是程序内打开。所以程序员建立了H5的承载容器,搭建了H5和本地交互的JSBridge内核,做了各种URL的容错处理,却在这种情况下依旧不能够实现产品的需求。产品自然是不乐意的,你们当时做了那么久连这个我想要的功能都没能实现。程序员也委屈的哭诉:我做的那么多你都看不见!其实这个归根究底是需求准确性的问题,程序员当时并没有准确的理解产品的需求,可能需求的表达上也没有那么准确的表示。要解决这种问题,可能就需要需求细致再细致,否则很可能会造成不同端程序员实现的不一样,导致功能不能如愿的使用。所以要想彻底解决的话,就不要存在任何的隐藏功能,做需求的时候就是字面的意思,有扩展的话麻烦需求讲清楚。

代码逻辑扩展偏差:程序员是需求的实现者,也是需求实现的设计者,这也是很多人觉得自己的代码是艺术品的原因。以为自己是以上帝的视角完整的实现的,但是真的如此么?真的了解自己代码的强壮性么?我们根据产品的需求写好了一个功能,就是从A页面跳到B页面。但是上到线上才发现崩溃率极高,细查发现从A跳到B没问题,从A跳到B再跳到C从C再返回A程序就崩溃了。看到这种问题,我们第一时间是后悔,后悔为什么没有想到这种场景,恰好测试也未能覆盖到这种场景。但是后悔也是无济于事,对于这种问题,我们除了多想想,代码review 外似乎没有更好的解决方法。其实我们可以进行程序员内部的功能review,就是让另一个跟你一样理解产品需求的人来点你的功能,点的话尽量从反方向来类推测试,这种测试可能会带给你意外的惊喜!

其实在工作中有bug王,也有那么几个极致的没有bug的人。他们往往更加安静,内心也是更加安静,写的代码行数可能不多,但是功能流畅,程序稳健,总是能将需求实现的恰到好处,没有让人看不懂的注释,更没有让人难以理解的骚操作。

其实,做程序员就是要把自己的能力、思维通过程序直接的展示给测试、产品、用户更是自己来看的,自己想的到的是来自他人的肯定而不是质疑。在遇到bug时,多一些思考少一些抱怨,只有自己多想多做才能在不断的磨合中更加完善自己。引用一句卖油翁的一句话:“我亦无他,惟手熟尔”。

2020年已经结束,2021继续做个让产品宠幸“无bug”小王子吧!

掘金年度征文 | 2020 与我的技术之路 征文活动正在进行中......