[{"createTime":1735734952000,"id":1,"img":"hwy_ms_500_252.jpeg","link":"https://activity.huaweicloud.com/cps.html?fromacct=261f35b6-af54-4511-a2ca-910fa15905d1&utm_source=V1g3MDY4NTY=&utm_medium=cps&utm_campaign=201905","name":"华为云秒杀","status":9,"txt":"华为云38元秒杀","type":1,"updateTime":1735747411000,"userId":3},{"createTime":1736173885000,"id":2,"img":"txy_480_300.png","link":"https://cloud.tencent.com/act/cps/redirect?redirect=1077&cps_key=edb15096bfff75effaaa8c8bb66138bd&from=console","name":"腾讯云秒杀","status":9,"txt":"腾讯云限量秒杀","type":1,"updateTime":1736173885000,"userId":3},{"createTime":1736177492000,"id":3,"img":"aly_251_140.png","link":"https://www.aliyun.com/minisite/goods?userCode=pwp8kmv3","memo":"","name":"阿里云","status":9,"txt":"阿里云2折起","type":1,"updateTime":1736177492000,"userId":3},{"createTime":1735660800000,"id":4,"img":"vultr_560_300.png","link":"https://www.vultr.com/?ref=9603742-8H","name":"Vultr","status":9,"txt":"Vultr送$100","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":5,"img":"jdy_663_320.jpg","link":"https://3.cn/2ay1-e5t","name":"京东云","status":9,"txt":"京东云特惠专区","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":6,"img":"new_ads.png","link":"https://www.iodraw.com/ads","name":"发布广告","status":9,"txt":"发布广告","type":1,"updateTime":1735660800000,"userId":3},{"createTime":1735660800000,"id":7,"img":"yun_910_50.png","link":"https://activity.huaweicloud.com/discount_area_v5/index.html?fromacct=261f35b6-af54-4511-a2ca-910fa15905d1&utm_source=aXhpYW95YW5nOA===&utm_medium=cps&utm_campaign=201905","name":"底部","status":9,"txt":"高性能云服务器2折起","type":2,"updateTime":1735660800000,"userId":3}]
作为以代码为生的软件开发人员，可用的功能与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无小事，质量意识心常存。
