程序员是这样炼成的（12）-勇于面对开发失败

 一个人一辈子不犯错很难，作为一个程序员要每天不制造程序错误更难。今天跟大家讨论如何面对失败和错误，大到一个项目的开发失败，小到几行代码中的bug,都是我们在日常开发中经常要面对的问题。

      有一家这样小公司，测试部和软件开发部是独立的两个部门，有各自的部门经理。老板总是喜欢给下面的员工施紧箍咒，施加压力，又是能力评估，又事绩效考核，于是某一年，在领导们别出心裁的领导下，公司出台了软件开发工程师的考核制度，制度明确规定：将程序员开发项目和软件的测试一次通过率和项目中的bug个数纳入开发人员的年终绩效考核，由测试部门进行考核和执行。（所谓一次通过率，就是软件提交测试后，一次通过的概率，一次测试就通过的软件/提交测试申请的软件数*100%）新法颁布后，测试部大呼过瘾，软件开发部一片哗然，第一年的过去了，果然“成绩喜人”，全公司的软件一次通过率达到了97%，无数未经测试软件被偷偷发布给了客户。第二年领导们在吸取了第一年的经验和教训后，毅然的修改了考核标准，在统计bug个数的同时融入了代码行数的概念，bug个数/100行代码 *100%来，进行年终考核，第二年过去了，软件开发部门戏剧化的以100行代码0.5的bug数，高效的开发质量给了领导们一个有力的答案。这是一个真实的事故，一个三流的软件公司的开发水平和软件质量已经“超越了”微软和google,我相信现在仍然还有很多公司在进行类似这个的考核。 

     这样的小公司把软件开发和测试部门独立本身就是一种错误，严重的影响的开发和测试的时间，两个部门相互扯皮，项目进展一拖再拖。

  其次，两个部门工作的出发点也错了，两个部门的工作重心是交给客户尽善尽美的软件产品，而不是为了应付考核和被考核。

  第三大错特错的考评制度，一看这样的制度，多半都是事不关己高高挂起的人出的主意，开发软件能一次就通过吗?写出来的代码能没有bug存在吗？公司要提高产品质量，不把注意力放在项目管理人，开发人员的能力培训上，开发规范和文档管理上，想凭借一纸空文，或者员工的主观能动就达到一个“质”的飞越，实在愚不可及！软件工程师在把软件测试N次以后才敢