<读书笔记>软件调试之道 ：问题的核心-修复后的反思

声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。欢迎转载！

--------------------------------------------------------------------------------------------------

有时尽管修复设计的是一个孤立的代码区，但你还是需要大局观，在修复缺陷之后花时间反思一下！

一旦确定了错误的来源，就可以采取措施避免它再发生！有些情况下，只不过是告诉你未来在在这一方面要更加小心！

在事后要反思并总结，尤其你发现了错误的模式只发生在特定的点或者特定的原因下时。极少数情况下，需要对自己敲响警钟！

1、问五个为什么，总体来说大部分情况下都能对你有帮助，比如：

• 软件崩溃了，出错了，为什么？
• 该代码不处理数据传输过程中的网络故障，为什么？
• 没有专门检测网络故障的单元测试，为什么？
• 最初的测试人员并没有意识到并创建一个这样的测试，为什么?
• 我们的单元测试没有考虑到软件故障，为什么？

可能很快就会得到，我们在原先的设计中没有考虑到软件故障这个问题症结，也可能有很多步骤。

2、根本原因分析

• 需求 需求是否完整、清晰并且未被误解？。
• 设计 在架构或者设计中是否存在疏漏，是我们没有考虑到还是没有正确的按照设计来做。
• 测试 对代码的测试是否达到了足够的覆盖率？或者测试本身就有问题呢？
• 构造 是开发人员写代码是犯了一个很简单的错误，或是误解了某些基础技术？

3、和同事交流问题注意事项

让同事知道他犯错了这件事情可能比较危险，一方面这个有价值的信息需要让同事知道以免其重蹈覆辙，另一方面，由于程序员不善交际沟通，可能由于口无遮拦把事情搞砸，所以你的善意可能得不到友好的回应，但是是需要做一些有益的事情。

• 首先最重要的，要有正确的出发点，不要只是为了得到自己的优越感。
• 在交流前，要三思并换位思考，如果自己犯错了该怎么办？
• 要清楚知道其性格特点！
• 避免妄作评判，不要说“你应该怎样”，而可以说“我们可以怎样”
• 要有建设性 要记住你也可能说错了!

4、关闭循环

如果你着手的项目有一套自己的规范：比如编码规范、测试规范、文档规范、报告/跟踪过程、设计指南、性能需求。当修复缺陷时，你是否需要更新最终用户文档作为修复记录？或为下一个版本更改日志？或者把它交给QA部门？该工作是否需要对特定客户或者项目进行跟踪（涉及到返修甚至召回）？