这几个月来，大部分业余时间，都花在阅读软件工程和编译原理方面的书籍上了。软件工程方面的书，包括软件需求、风险管理、敏捷建模，系统设计，软件项目管理，还有一些类似于的沉思录书籍等。

 

在这些书中，都只是讲了如何让项目健康发展，最后成功的提交一个产品。尽管它们都是从不同的角度，用不同的方法去完成同样的事。但它们几乎都支持这样的观点：计划+修正计划（不但设计是迭代的，计划也是迭代的）。用其中一个作者的话说，伤害你的，不是那些你没有考虑完整的，而是你根本没去考虑的事情。

 

然而，几乎没有一本书里，讲到关于消防队的事，唉，真是奇怪，老外声称有超过50%的项目是失败的，那么在他们的项目中，失火也是常事，为什么就不谈谈救火的招数呢？难道他们也相信，不叫出魔鬼的名字，魔鬼就不会找上门来吗？

 

唯一的解释就是，救火太难了，可能老外的救火能力远不如我们，他们干脆就不谈了。我在上一个项目中牺牲惨重，巨大的压力之下，和女友分手，精神上和身体上都受到极大的伤害，当然，我不是那个项目唯一的牺牲品，很多同事，他们很优秀，也一样的无助。之后，我一直在想，既然有50%的项目会失火，那么救火能力和计划能力至少是等同重要了。我苦苦的思索，回忆上次的经历，查找相关资料，然而收获甚微。

 

救火的银弹也许永远不会出现，我把自己一些经验写出来，或许对大家有点帮助，如果能达到抛砖引玉的效果那是更好了：

 

1.         在FIX BUG过程中，持续进行重构。在设计时没有做好，重做是不太可能的了，但绝望也是没有意义的，我们只能想法去改进它。利用前人一些经验，持续进行重构，每FIX一个BUG，我们让代码更好一点，而不是更坏一点，FIX了一个BUG，代码中就少了一个BUG，而不是引更多的BUG。在实际上，重构最大的困难是没有完整的自动测试程序和测试用例，这使得我们根本不敢去改动代码，或者为了让改动最小，采取一些折中的方法，这都使得代码不断的变臭。在这种情况下，建议是建立自动测试，然后不断完善测试用例，我觉得建立自动测试任何时候都不晚。如果建立自动测试确实比较困难，那就列出所有的测试用例，然后手工测试。这时候，工程师的工作就是：重构à测试àFIX BUGà测试。有人说，我没有时间去重构，没有时间去测试。呵，这会使我想到，一个人围绕着一个小圆圈拼命的奔跑，累得半死的时候，发现在原地，他还在说，我没有时间去看清方向。

 

2.         关注常用功能。在项目的最后阶段，千万不要被QA牵着走，他们发现一个BUG，我们就FIX它。FIX一个BUG当然好，但是FIX BUG不是免费的，要不但要成本，还有潜在的风险。编译的优化原理是基于：20%的代码花了80%的时间。如果这个原理成立，可以推出：80%的用户实际上只使用20%的功能。QA并不是最终用户，QA和最终用户的不同在于：QA尽力去发现不常见的问题，而最终用户经常使用最常用的功能。这时候我们可以把自己想成最终用户，列出最常用的测试用例，如果不在这些测试用例中的情况，即使BUG的现象很严重，我们也要考虑一下再决定是否修改它。

 

3.         确定哪些BUG不改同样重要。这一点与2有一定的重复，为了强调有必要单独提出来。在软件需求分析时，分析师们都认为，要确定什么不在系统内和什么在系统内一样重要。程序员对于BUG态度，有时往往走两个极端：一种是老子就不改。一种QA怎么说我就怎么改。前者往往被看着工作态度不端正。而后者呢，却被视为好孩子。其实，在项目的最后阶段，后者未必正确，正如前面所说，FIX BUG不是免费的。这时候建立一个仲裁委员会有必要的，确定哪些BUG不改是他们的职责之一。

 

4.         BUG分类，明确责任。以前接手别人一个模块，处于Pending状态的BUG已经有110多个了。要把每一个BUG都看一遍就要花几个小时，不看吧，每次改一个BUG时，总有只见树木不见森林的感觉。最初，我很努力的去修改BUG，进展还是甚微。后来我花了几天时间，仔细分析了所有BUG，把它们归纳几类：其它模块引起的BUG; 和其它模块的接口引起的BUG; 超出需求之外的BUG; 完全是本模块内部的BUG。然后把其它模块引起的BUG提交给相关人员，和相关人员确认因接口不统一引起的BUG，把超出需求之外的BUG提交给需求控制委员会，最后剩下本模块的BUG又根据引起BUG的原因分为几类。这样，这些BUG很快被FIX了。

 

5.         工程师应该积极寻求帮助。有什么自己解决不了问题，应该向知道的人请教，或者向上司寻求帮助，不要出于面子或者其它原因，而花费大量的时间。在项目的最后阶段，每一分钟都很宝贵，不要重新发明轮子，对于有共性的难题也应该由专人解决。

 

6.         项目经理应该把眼光放在全局上。项目经理应该更多的关注于全局的事务，不要学只想拿大红花的小学生。别只顾修改自己的BUG，你的BUG少，并不能说明你是个好项目经理，在项目失败时，你个人的BUG少，并不能真正减轻你的罪恶感。据说软件团队遵循水桶原则，最低的那块木板才是决定装多少水要素，而不是最高的那块。项目经理应该随时关注哪块是最低的，然后把它补起来，自己成为最高的那块是没有意义的。

 

7.         Person Review以提高士气。呵，不知道有没有Person Review这个术语，反正我觉得挺好的，在项目的最后阶段，士气是非常宝贵的东西，可以说得士气者得天下。在前一个公司，每周一，老板会把每个工程师叫到他的办公室，一起聊会儿，聊天内容不限，多半是问问你这边工作上存在什么问题，有什么看法，非常坦白的谈一会儿，最后会得到他的鼓励和赞扬，自己感觉这对提高士气很有帮助的，当然老板最好是个好的煽动者。

 

8.         Bug Review。建立一个Bug Review小组，他们的主要责任是： 发现一些具有共性的BUG，确认哪些BUG需要FIX，哪个BUG不用FIX。有共性的BUG，让专人解决或者督促。不管一个BUG是要FIX还是不用FIX，都要注明足够的理由。

 

9.         加强QA和RD之间的合作。呵，根据遗传学和适者生存原理可以知道，在最后阶段，BUG的生命力极强，往往花费很长时间才能重现。加上自然语言本身具有的二义性和个人看问题的侧重点不同，QA可能忽略了RD让认为很重要的重现步骤，QA的BUG描述在RD眼中也可能迥然不同。在这个阶段，直接到现场和QA交流一下，可能会节省很多时间。同时也要尊重QA的劳动成果，这样他们才会更积极的配合。

 

10.     经验积累。每遇到一个BUG，想一想，它为什么会出现，为什么才出现，修改它后会有什么后果。把重要的记录下来，可能对自己和别人都有所启发，以减少犯同样错误的机会。