随笔分类 - 读书笔记之软件调试
摘要：模式是用来解决常见的、反复出现的问题。反模式是一种另类的模式，指我们反复犯的一些常见错误，了解反模式是避免发生错误的第一步。如果你发现自己面临着夸大优先级的问题时，那么可以采用如下方法：1. 定期清除你的缺陷，控制缺陷数据库2. 控制缺陷的优先级，允许用户指定严重性而不是优先级3. 不要用数字来表示优先级，按照优先顺序把缺陷列出来巨星效应会破坏团队。确保开发过程包含足够的检验机制和平衡机制：1. 确保“完成就是完成”，当前工作完成之前不允许任何人进入下一个任务。2. 将大任务分解成具体的小任务。3. 采用“自负自责”的原则，谁造成了缺陷谁就负责修复它。从最初的构思到最终部署，整个过程用同一个团
阅读全文
摘要：有很多书或文章都在探讨如何编写好软件，但很少有讨论如何编写容易调试的软件，幸好，如果遵从创建良好软件的一般原则，即分离问题、避免复制、隐藏信息，并创建结构良好、易于理解和修改的软件，那么就能编写出容易调试的软件。良好的设计与调试并无冲突。代码的每一块都建立在一个无数假设的平台上——某些条件必须是正确的才能让运行结果符合预期，往往缺陷的出现是因为某些假设是不成立的或者是错误的。避免做出这些假设是不可能的也是没意义的，我们不仅可以验证它们，也可以通过断言来自动验证。断言长什么样？在Java里有两种格式，一种简单的格式：assert <condition>; 还有一种格式包含一条信息，若
阅读全文
摘要：调试过程是不会发生在真空中的，因此提前了解基本知识，未雨绸缪，等你真的遇到一个缺陷时，会为你节省大量时间、精力并减少挫折感。有效的自动化测试不仅仅意味着简单地使你的测试自动化，为了达到效益最大化，你的测试必须满足：明确说明测试的结果是通过还是失败，每个测试输出一个结果——通过或者失败。独立，运行一个测试程序之前不需要安装，测试运行前，能够自动安装任何它需要的环境，测试后能撤销对环境的修改。单击运行所有测试，所有测试都可以一步运行，不会互相影响。全面覆盖，做到接近完全覆盖是有可能的。调试的时候是什么让自动化测试更有价值呢？首先，经过良好测试的代码往往只有少量缺陷，最容易修复的缺陷就是根本不存在的
阅读全文
摘要：调试对于软件开发至关重要，然而调试并非是件容易事，Paul Butcher的这本《软件调试修炼之道》是一部非常优秀的软件调试实战指南，很多人光看标题，以为这本书只是在讲blackbox/whitebox testing, unit testing, regression testing, etc. 其实，作者根本没专门把这些Testing 101的内容拿出来讲。书的内容除了debug，还涵盖了很多『好』的软件开发方法。所谓的『好』的开发方法，就是要保证软件质量，保证开发进度，保证写出来的代码可维护。说真心话，这本书真的是软件工程方面的好书。而且这本书写的通俗易懂。它不需要读者拥有5年、10年以
阅读全文
摘要：特殊案例之一就是修补已经发布的软件，诊断这种缺陷与其他缺陷并没有什么不同，但修复的目标通常是要修复错误的根源，而对已经发布的软件要进行修补时，他只是在最大程度降低风险。如果缺陷出现在用户已经使用的软件中，那么需要考虑向后兼容的问题。首先需要确定正在进行的修复是否可能引起兼容问题，此时，我们能做的就是对整体了解的基础上思考，将确定兼容性问题加入到缺陷修复的检查列表中，一旦确定有兼容性问题，该如何解决呢？1. 提供迁移的方法：给用户提供一些方法来修改其现有数据，代码等东西，以适应新的规则。2. 实现一个兼容模式：比如office word 2010打开word 2003版本显示如下：这不是一个能被
阅读全文
摘要：本章主要内容有：什么时候修复缺陷？调试的思维模式自己如何解决质量问题早期修复缺陷基于两个原则：1. 那些可能发现缺陷的过程（测试、代码审查、用户使用）要连续贯穿于整个开发过程中2. 缺陷修复优先于其他任何事情目的：保证软件中存在的缺陷数量尽可能少。早期的缺陷检测和修复能帮助你估算在缺陷修复上大约需要多少时间并以此来修改测试计划。调试时一种心理活动。爱丽丝：再试也没用，人们不可能去相信不可能发生的事。怀特女王：我敢说你练的还很不够，我在你这么大的时候，每天做它半小时，有时在早餐前，我就相信有不可能的事情要发生。缺陷是不可避免的，无论多么努力，总会遗漏一些问题，因此不必去担心缺陷的发生，接受总会有
阅读全文
摘要：之前的部分我们都假定已经知道软件存在缺陷，那么在这一章中，我们要看看在此之前，需要做什么呢？本章重点讲述三方面内容：缺陷追踪：使用缺陷追踪系统获取它所提供的信息，当发现缺陷时，记录下具体的，明确的，最小化的，唯一的缺陷报告，通过软件增加选项来自动收集环境和配置信息。与用户合作：用户很少会花时间来报告缺陷，即使报告了也不能保证缺陷的高质量，但我们可以简化整个流程来让用户帮助我们获得关于缺陷的更多信息。1. 在About对话框中，或者在线帮助网站等地方向用户解释如何报告缺陷2. 安装顶层的异常处理程序，给用户发送缺陷报告选项，记录下相关细节，比如office发送报告对话框3. 提供多种选择让用户发
阅读全文
摘要：缺陷修复的目标极其明确，但有时候修复的过程涉及的只是一个孤立的代码区，因此，修复完缺陷后有必要花时间反思以下几个问题。这到底是怎么搞的？当你对缺陷怀抱这样的疑问时，尤其在修复完后依然怀抱这样的疑问时，很大程度上表明你还没有真正完全了解缺陷所揭示的东西，请继续思考下去，弄明白它究竟是怎么搞的，极可能会从中学到很多东西。哪里出了问题？这是从缺陷中吸取教训的第一步，有时候甚至需要思考，软件最开始是如何产生这个错误的呢？如果起初开发的代码中隐藏着缺陷，那么究竟发生在需求的模糊不清造成的误解上，还是架构设计的疏漏里，又或者是测试本身的缺陷还是构造造成的呢？它不会再发生了！一旦确定了错误来源，就可以采取措
阅读全文
摘要：当问题诊断告一段落，很可能你已经完成了任务中最困难的部分了，但是，依然要小心，你必须知道，对于一个好的修复来说，不仅仅是让软件能够正常运行，你还需要为将来奠定良好的基础。缺陷修复的三个目标：修复问题，避免引入回归，维持或提高代码的整体质量（可读性、架构、测试覆盖率等）假设你的开发过程包括测试驱动（测试优先）开发，你拥有一个自动化测试框架和大量的单元测试工具，当你要对源代码进行修改的时候，这种方法确实能收到良好的效果，不仅可以用它来确保你的修复程序会解决此问题，还为它避免卷入回归提供了很好的保障。测试优先开发规则之一：直到有一个失败的测试时，才应该更改源代码。因此，你需要证明你已经拥有了通过所有
阅读全文
摘要：在诊断期间有无数的方法会误导人，因此这里我们来一起看看所谓的陷阱。你做的修改是正确的吗？如果你做的修改似乎没有任何效果，那么你并没有改到点子上，因此要在潜意识里时刻提高警惕。验证假设：了解你正在做什么样的假设，对它们进行严格的检验。多重原因：面临多种原因的最常见信号是一种你处于模糊状态的感觉——发生了一些似乎没有明显解释的怪事情，最富有成效的解决多原因缺陷的办法是对问题进行隔离，并找到一个方法来重现缺陷，重现的缺陷产生的原因只依赖于多个原因中的一个，而不依赖于其他原因。另一个方法是开始先找寻同一区域内其他较明显的缺陷，处理这些缺陷有时可以扫清障碍，让你理解得更透彻，使初始问题更加凸显。流沙：模
阅读全文
摘要：诊断问题时程序调试的关键，这个阶段，我们可以开始解决缺陷问题了，你可以了解看到的运行结果背后的根本原因。真正有效的缺陷修复要求思维方式既开放又有条不紊，解决方法既创新又注重全面综合，这和软件开发的其他很多方面是一样的。一种调试方法：提出一个可能提供解释的假设，然后再构建实验去证明你的假设，如下：1. 按照你对软件运行情况的理解，提出一个可以导致这种运行状况的假设2. 设计一个实验，证明你的假设正确与否3. 如果你设计的实验不能证明你的假设，那么重新设计一个实验，然后再次进行实验4. 如果实验支持你的假设，那么继续进行实验，直到能证明或伪证你的假设这种方法十分有效，但却十分抽象，怎么才能把它转化
阅读全文
摘要：不管是什么样的重现问题的方法，只要有，就比没有强。但是如何让重现问题既可靠又方便呢？最小化反馈周期：和软件开发的其他众多领域一样，问题重现也是要使反馈周期最小，所经过的周期越短，反馈就越及时，其相关性就越高。因此，最先要关注的就是找出问题重现中哪些方面是不需要的，将它们剔除掉，称为将问题重现最小化。那么，哪些元素可以被剔除呢？往往这要靠直觉。你了解软件，并且知道哪些模块可能被一些特定输入所影响，如果直觉不对，那么一些非直接的方法可能会帮助到你。改进问题重现不是一蹴而就的事，而是在整个诊断过程中要牢记在心的东西。将不确定的缺陷变为确定的：要做到这一点，需要明白不确定性从何来？1. 开始于不可预知
阅读全文
摘要：运用实证（实证依赖的是观察和经验，而不是理论和纯逻辑推理）方法进行调试可以充分利用软件的独特能力来告诉你软件运行的状态，而发挥这种能力的关键是找到能够重现问题的方法。为什么重现问题如此重要？不能重现问题，就几乎不可能取得进展，因为实证过程依赖于我们观察存在缺陷的软件执行的能力。如何重现？要做的第一件事很简单，就是按照缺陷报告描述（或提示）的步骤做，要做好问题重现就要抓好控制，而需要控制的因素如下：1. 软件本身 如果缺陷存在于最近修改的地方，那么你应该首先保证你调试运行的软件和缺陷被提交时使用的软件是同一个版本2. 软件的运行环境 如果要与外部系统进行交互，那么可能需要确保你使用的是相同的..
阅读全文
摘要：什么是调试？调试的目标是什么？调试就是查明问题的根本原因，这是一切事情的基础！看到过很多文章，设计，代码，需求，方法……可是很少看到有人写调试，是因为它太容易，所以不屑一提，还是因为它太细节，不易描述？对于高手来说，调试也许轻而易举，哪怕不知道如何描述调试，至少知道如何调试，可是，很多初学者并没有调试的概念，也不知道如何调试。问自己这么一个问题：当程序遇到问题的时候，你是用心的在分析原因，还是仅仅凭着直觉进行修改？调试，其实不容易，它比其他任何过程都需要动脑，它不发生在调试器或者代码中，而是形成于大脑中，找到并理解问题的根源，才能进行其他的工作。最近看到这本Paul Butcher的《软件调试
阅读全文