声明:本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher,属于读书笔记。欢迎转载!
--------------------------------------------------------------------------------------------------
有时尽管修复设计的是一个孤立的代码区,但你还是需要大局观,在修复缺陷之后花时间反思一下!
一旦确定了错误的来源,就可以采取措施避免它再发生!有些情况下,只不过是告诉你未来在在这一方面要更加小心!
在事后要反思并总结,尤其你发现了错误的模式只发生在特定的点或者特定的原因下时。极少数情况下,需要对自己敲响警钟!
1、问五个为什么,总体来说大部分情况下都能对你有帮助,比如:
- 软件崩溃了,出错了,为什么?
- 该代码不处理数据传输过程中的网络故障,为什么?
- 没有专门检测网络故障的单元测试,为什么?
- 最初的测试人员并没有意识到并创建一个这样的测试,为什么?
- 我们的单元测试没有考虑到软件故障,为什么?
可能很快就会得到,我们在原先的设计中没有考虑到软件故障这个问题症结,也可能有很多步骤。
2、根本原因分析
- 需求 需求是否完整、清晰并且未被误解?。
- 设计 在架构或者设计中是否存在疏漏,是我们没有考虑到还是没有正确的按照设计来做。
- 测试 对代码的测试是否达到了足够的覆盖率?或者测试本身就有问题呢?
- 构造 是开发人员写代码是犯了一个很简单的错误,或是误解了某些基础技术?
3、和同事交流问题注意事项
让同事知道他犯错了这件事情可能比较危险,一方面这个有价值的信息需要让同事知道以免其重蹈覆辙,另一方面,由于程序员不善交际沟通,可能由于口无遮拦把事情搞砸,所以你的善意可能得不到友好的回应,但是是需要做一些有益的事情。
- 首先最重要的,要有正确的出发点,不要只是为了得到自己的优越感。
- 在交流前,要三思并换位思考,如果自己犯错了该怎么办?
- 要清楚知道其性格特点!
- 避免妄作评判,不要说“你应该怎样”,而可以说“我们可以怎样”
- 要有建设性 要记住你也可能说错了!
4、关闭循环
如果你着手的项目有一套自己的规范:比如编码规范、测试规范、文档规范、报告/跟踪过程、设计指南、性能需求。当修复缺陷时,你是否需要更新最终用户文档作为修复记录?或为下一个版本更改日志?或者把它交给QA部门?该工作是否需要对特定客户或者项目进行跟踪(涉及到返修甚至召回)?
时间: 2024-11-05 06:21:52