作为以代码为生的软件开发人员,可用的功能与Bug总是相生相克。有次产品迭代回顾会上,我提出低级Bug数量要作为KPI之一进行绩效考核,私底下某些小伙伴反响挺激动:写怎么可能没有Bug,怎么会有这么傻X的要求?如果真的是Bug数量的多寡来考核写代码的开发同学,相信大家都会疯,这是制度上的缺陷,不利于组织的发展。

题图 from pixabay

他确实曲解了我的用意,我不是要考核Bug数,而是考核低级Bug数,什么是低级Bug?写过几年代码,大概都分的清Bug的严重程度。

*
界面上的样式问题,格式不统一、错乱、错别字

*
极简单的空值判定问题,稍微自测就能暴露出来

*
常用代码使用不规范,

*
系统上线数据库连接错乱

*
完全复制别人的类似代码不加思考直接据为已用

*
......

相信还能罗列很多,这种写出来的没有技术含量的Bug,摆在台面上,相信自己都会脸红,这些问题不需要有很好的技术水平才会犯。低级问题都有很好的套路可以避免:遵循普遍的代码规范,单元自测,遵照特定的流程,细心+认真。

为什么要考核低级Bug数,低级Bug数不是考察你的技术能力高低,它反映的是一个人的工作态度问题。一个好的工作态度胜过一个不负责任的技术大牛,那为什么不考核Bug数?Bug的多寡源自于代码开发量的多寡,做的多,错的就多。做的少,就错的少。不做就不错。如果按这个标准走,对大家是不公平的,这个组织就不会有长足的发展。一个学习型组织的成员,必须抱着成长的心态向前走,而不是怕出错误就不往前走。

还有一个Bug数指标也可以做为KPI项考核呢?Bug重复打开率
。一个Bug被Fixed掉之后,过段时间又被再次打开,说明没有彻底解决掉,在某些场景下依旧存在。或者当前问题解决了,引发了另外的Bug,在另个的Bug被解决掉之后,当前的Bug又被重新打开了,也就是大家常说的“改好一个,坏了仨”,越改,Bug越多。

当大家不重视代码质量,无感Bug数的时候,团队就会形成一种潜意识——Bug无所谓,出现了改就是了,如此而来的产品质量肯定不会高到那里去。当然也不能高压控制Bug,出现一个扣多少多少钱,只会让团队萎缩不前。因Bug导致的生产事故,依据大小,是可以进行处罚,相信大家也不会太大怨言。

Bug无小事,质量意识心常存。

技术
今日推荐
阅读数 21
阅读数 16
阅读数 10
阅读数 9
友情链接
码工具
Toolsou
API参考文档
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信