码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2016-06-04 08:10:18      阅读:249      评论:0      收藏:0      [点我收藏+]

标签:

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

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

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

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

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

 

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

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

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

2、根本原因分析

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

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

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

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

4、关闭循环

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

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

标签:

原文地址:http://www.cnblogs.com/shuolang/p/5558068.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!