1、查证问题确已被修复
如果遵循了“制造失败”这条规则，就知道如何验证你确实修复了问题。无论问题和修复看起来多么明显，你都无法保证修复是有效的，直到做了测试并验证。
2、查证确实你的修复措施解决了问题
如果你取消这个修复，系统再次出现失败，再应用这个修复，问题消失，才能够证明你确实修复了问题。这样做的原因是，在调试期间，往往会改变一些不属于修复的地方，有时这些改变会隐藏问题，如果没有意识到这一点，发现测试起作用了，就高高兴兴的回家了，因为你做的修复和问题消失毫无关系，因此修复方案到达客户后，可能再次失败甚至更糟！ 但是这个也有例外，比如已经坏掉的硬件不需要再装回去验证。就像心脏手术中不需要把原来的心脏再装回去验证一样。
3、要知道，bug不会自动消失
如果你不修复bug,它不会自动修复，也许看起来不再发生了，但是它仍会发生。 比如随机出现的bug，如果凭猜测修改了很多地方，或许碰巧修车成功了，或许只是把它隐藏起来了，但你并不知道怎么解决的，下次发生时，你还是毫无头绪。
如果基于发布，没有时间追踪随机bug,也可以在发布的系统中进行插桩，当故障发生时，可以捕获一些信息，如果问题不发生，也不会有任何影响。这样做的一个好处是，及时你无法利用这些信息来修复问题，起码让客户知道你认真跟踪了问题，通过对客户反馈的信息进行感谢，比向客户说我们从未遇到这个问题要好。
4、从根本解决问题
如果一个硬件损坏了，不要简单更换了事，如果其在某种情况下会损坏，这样只会给你换来一点时间，新的零件还是会损坏。 比如，电路板上的电容耐压值5V，但是你的系统峰值电压偶尔会达到8V，那么简单更换电容后，它仍然会损坏，必须找到器件损坏的原因，才能从根本解决，比如更换耐压值为16V的电容。
5、对过程进行修复
有时修复系统和修复过程很难区分，有时bug隐藏在设计的过程中，而不是产品中，这个方面涉及到了设置质量的问题。 比如一家生产车间的地板上有油滴，如果简单的擦拭掉，过几天还会出现，查找原因后才发现，公司的产品使用两个螺钉固定，当受到剧烈震动后，螺钉会松动导致漏油，因此必须修改设计，以确保产品在需求、设计和验证正确考虑震动。
总结
- 要合理利用版本控制和管理工具
- 要有调试测试记录文档和bug记录系统，便于备份、总结和查找。
- 要勤于学习，持开放心态，积极面对问题。
- 要遵循前面的九条规则，遇到问题不要慌乱，不要主观臆断问题根源，不要随意改动，以免导致更加严重的后果