此刻我正看着他的Bug统计报表，整个项目目前还处于轮次测试中的第一轮，但bug数目已经达到100+。
究竟要不要以Bug论英雄，我说了不算，用户的使用反馈才算。
可项目测试中，Bug率这么高，项目质量能好吗？
毕竟测试并不能提高代码质量，相反，Bug越多潜在的问题也越多。
Bug率作为评估程序员绩效的标准
曾经有幸和华为工作的测试工程师谈过这个问题，华为一直以狼性文化著称，自然在程序员的绩效评估上，也有Bug的身影。
这位华为的同事告知我，每次提Bug都要和开发“打架”。
没有一场激烈的争斗，开发是不会承认Bug的，有时甚至开发和测试吵不过，要拉着开发队长和测试队长一起吵。
最后谁能胜利，就看Bug到底是什么了。
这也反映一个问题，究竟Bug作为评估程序员绩效的标准好不好？对工作有没有起到正面的推动作用？
华为程序员的能力毋庸置疑，毕竟能进入顶尖大企业写代码，业务员能力肯定是杠杠滴。
但开发能力牛逼，不一定说，写的代码就没有Bug，毕竟能保证说自己的代码没有Bug的程序员还没诞生呢，否则，测试工程师可不就要失业了吗。
那么将Bug率作为绩效评估，对华为同事的工作影响是正面的吗？
测试的同事就一句话：心累。开发的同事也一句话：心累。
而且隐隐约约，开发和测试总是对立面，沟通时候总带些火药味。
Bug率与绩效无关
前同事最近和我吐槽说：开发很不责任。
我问：怎么呢？
她说：开发明知道有Bug也不改，非要测试提出来才改。
我一笑，这不是当前很多程序员的通病吗。认为找Bug是测试的事，生产环境出现Bug就是测试没找出来，反正都是测试的责任。
这样导致的后果就是，开发很随性，测试很痛苦。
而且通常这样的公司对于测试的地位也是不认可的，毕竟测试不是输出型的岗位，没有实质性的产品输出自然不容易让人看到价值。
如果说，测试的工作是找bug，那开发的工作是制造Bug。
按照谁污染谁治理的原则，开发也有义务找出Bug并修改，代码走查是必要的，单元测试、接口测试也是必要的。
找出Bug要及时修改，如果是友好型的开发也可以给测试友善提醒修改哪些范围，代码影响范围，功能影响范围。毕竟在哪里开了刀只有开发才最清楚。
当然，以上都只是个别样本，不代表大众，但也能说明一些问题。
不论负责什么项目，开发和测试也是一个团队，没有说Bug就全部是测试或开发单一方面的责任。
Bug率要不要作为绩效考核，最重要的是员工要有责任心，力求将产品做好，而不是应付了事。
