©2020-2024 ioDraw All rights reserved,
Privacy Policy
作为以代码为生的软件开发人员，可用的功能与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无小事，质量意识心常存。