标签：
声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。欢迎转载！
--------------------------------------------------------------------------------------------------
有时尽管修复设计的是一个孤立的代码区，但你还是需要大局观，在修复缺陷之后花时间反思一下！
一旦确定了错误的来源，就可以采取措施避免它再发生！有些情况下，只不过是告诉你未来在在这一方面要更加小心！
在事后要反思并总结，尤其你发现了错误的模式只发生在特定的点或者特定的原因下时。极少数情况下，需要对自己敲响警钟！
1、问五个为什么，总体来说大部分情况下都能对你有帮助，比如：
可能很快就会得到，我们在原先的设计中没有考虑到软件故障这个问题症结，也可能有很多步骤。
2、根本原因分析
3、和同事交流问题注意事项
让同事知道他犯错了这件事情可能比较危险，一方面这个有价值的信息需要让同事知道以免其重蹈覆辙，另一方面，由于程序员不善交际沟通，可能由于口无遮拦把事情搞砸，所以你的善意可能得不到友好的回应，但是是需要做一些有益的事情。
4、关闭循环
如果你着手的项目有一套自己的规范：比如编码规范、测试规范、文档规范、报告/跟踪过程、设计指南、性能需求。当修复缺陷时，你是否需要更新最终用户文档作为修复记录？或为下一个版本更改日志？或者把它交给QA部门？该工作是否需要对特定客户或者项目进行跟踪（涉及到返修甚至召回）？
标签：
原文地址：http://www.cnblogs.com/shuolang/p/5558068.html
