摘要: 当问题诊断告一段落,很可能你已经完成了任务中最困难的部分了,但是,依然要小心,你必须知道,对于一个好的修复来说,不仅仅是让软件能够正常运行,你还需要为将来奠定良好的基础。缺陷修复的三个目标:修复问题,避免引入回归,维持或提高代码的整体质量(可读性、架构、测试覆盖率等)假设你的开发过程包括测试驱动(测试优先)开发,你拥有一个自动化测试框架和大量的单元测试工具,当你要对源代码进行修改的时候,这种方法确实能收到良好的效果,不仅可以用它来确保你的修复程序会解决此问题,还为它避免卷入回归提供了很好的保障。测试优先开发规则之一:直到有一个失败的测试时,才应该更改源代码。因此,你需要证明你已经拥有了通过所有 阅读全文
posted @ 2013-02-21 17:26 Ribbon 阅读(342) 评论(0) 推荐(0) 编辑
摘要: 在诊断期间有无数的方法会误导人,因此这里我们来一起看看所谓的陷阱。你做的修改是正确的吗?如果你做的修改似乎没有任何效果,那么你并没有改到点子上,因此要在潜意识里时刻提高警惕。验证假设:了解你正在做什么样的假设,对它们进行严格的检验。多重原因:面临多种原因的最常见信号是一种你处于模糊状态的感觉——发生了一些似乎没有明显解释的怪事情,最富有成效的解决多原因缺陷的办法是对问题进行隔离,并找到一个方法来重现缺陷,重现的缺陷产生的原因只依赖于多个原因中的一个,而不依赖于其他原因。另一个方法是开始先找寻同一区域内其他较明显的缺陷,处理这些缺陷有时可以扫清障碍,让你理解得更透彻,使初始问题更加凸显。流沙:模 阅读全文
posted @ 2013-02-21 16:51 Ribbon 阅读(269) 评论(0) 推荐(0) 编辑
摘要: 诊断问题时程序调试的关键,这个阶段,我们可以开始解决缺陷问题了,你可以了解看到的运行结果背后的根本原因。真正有效的缺陷修复要求思维方式既开放又有条不紊,解决方法既创新又注重全面综合,这和软件开发的其他很多方面是一样的。一种调试方法:提出一个可能提供解释的假设,然后再构建实验去证明你的假设,如下:1. 按照你对软件运行情况的理解,提出一个可以导致这种运行状况的假设2. 设计一个实验,证明你的假设正确与否3. 如果你设计的实验不能证明你的假设,那么重新设计一个实验,然后再次进行实验4. 如果实验支持你的假设,那么继续进行实验,直到能证明或伪证你的假设这种方法十分有效,但却十分抽象,怎么才能把它转化 阅读全文
posted @ 2013-02-21 16:18 Ribbon 阅读(466) 评论(0) 推荐(0) 编辑
摘要: 不管是什么样的重现问题的方法,只要有,就比没有强。但是如何让重现问题既可靠又方便呢?最小化反馈周期:和软件开发的其他众多领域一样,问题重现也是要使反馈周期最小,所经过的周期越短,反馈就越及时,其相关性就越高。因此,最先要关注的就是找出问题重现中哪些方面是不需要的,将它们剔除掉,称为将问题重现最小化。那么,哪些元素可以被剔除呢?往往这要靠直觉。你了解软件,并且知道哪些模块可能被一些特定输入所影响,如果直觉不对,那么一些非直接的方法可能会帮助到你。改进问题重现不是一蹴而就的事,而是在整个诊断过程中要牢记在心的东西。将不确定的缺陷变为确定的:要做到这一点,需要明白不确定性从何来?1. 开始于不可预知 阅读全文
posted @ 2013-02-21 12:30 Ribbon 阅读(454) 评论(0) 推荐(0) 编辑
摘要: 运用实证(实证依赖的是观察和经验,而不是理论和纯逻辑推理)方法进行调试可以充分利用软件的独特能力来告诉你软件运行的状态,而发挥这种能力的关键是找到能够重现问题的方法。为什么重现问题如此重要?不能重现问题,就几乎不可能取得进展,因为实证过程依赖于我们观察存在缺陷的软件执行的能力。如何重现?要做的第一件事很简单,就是按照缺陷报告描述(或提示)的步骤做,要做好问题重现就要抓好控制,而需要控制的因素如下:1. 软件本身 如果缺陷存在于最近修改的地方,那么你应该首先保证你调试运行的软件和缺陷被提交时使用的软件是同一个版本2. 软件的运行环境 如果要与外部系统进行交互,那么可能需要确保你使用的是相同的.. 阅读全文
posted @ 2013-02-21 10:47 Ribbon 阅读(970) 评论(0) 推荐(0) 编辑