第二章 过程改进，没有灵丹妙药

    当一个Bug被解决，它将被自行指派给发现它的人。如果这个人不是开发团队的人员，那这个Bug必须指定给另一个团队中的人，这个人可以跟Bug发现者核实解决方案。但你不能总是指望团队外部的人能及时周到地确认解决方案。当然，如果这个解决方案不怎么令人满意，那么这个Bug应被重新激活。

    作者注：我第一次为我的团队制定解决方案是在10年前。回顾之前的邮件，以上定义至今仍然有效。

    过犹不及

    Bug报告中还有很多其他区域。我说过用“创建”及“环境”两个区域记录Bug相关信息以及用“等待修复”区域来说明什么时候处理Bug。还有一些区域用来跟踪记录底层原因，这个Bug是怎么被发现的，Bug是在产品或服务的哪个方面发生的，潜在的安全威胁以及其他信息。

    设定好Bug报告的必要条件，少则缺，多则无益。要求太多人们会怨声四起而拒绝完成Bug报告——两种极端都会对你及你的客户不利。

    Bug报告要易写且易读，这样会促使他们在发现问题的时候制定清晰的Bug报告。使用一些Bug模板对于一些内容的编写是很有帮助的。对于我们在乎的工程师及客户来说，规范的Bug报告使一个问题在用户发现前消灭于萌芽状态，没有比这更好的礼物了。