声明：本文档的内容主要来源于书籍《软件调试修炼之道》作者Paul Butcher，属于读书笔记。欢迎转载！
--------------------------------------------------------------------------------------------
缺陷优先
如何使缺陷修复与软件开发相结合？
如何估计缺陷修复花费的时间？
如何确保项目不会陷入《人月神话》中所描述的无数缺陷修复的焦油坑中呢？
- 缺陷优先
- 要采用早起缺陷修复原则，并且基于以下两个原则
- 测试、代码审查、让用户使用软件要贯穿于整个开发过程中
- 缺陷修复要由于其它任何事情
- 早期缺陷修复可以大大降低软件运行的不可靠性，并估计修复上所需要的大概时间以调整你的测试计划，后期修复只会积累技术债务，也不知道何时能修复他们并结束项目。
- 质量低下具有传染性，因此要没有破窗，软件开发与维护，是一个持续与熵抗争的过程
2.调试的思维
- 调试首先是一种心理活动，要保持健康的调试心态。天真的说，“没有破窗”可以被理解为只有绝对完美的情况下才能实现。任何参加过软件开发的人都知道，缺陷不可避免，无论多么努力，总会有遗漏，如何解决这个问题？
- 最有效的思维模式是务实的零容忍策略，非常接近于零，但是用务实的心态去实现，虽然我们远远做不到完美，但是可以用正确的方式无限的接近它。
- 采取无破窗策略时，要分清是缺陷还是特性，缺陷是无意识行为，其它都是特性，对于客户来说二者可能一样，但是软件开发人员要分清，并且要明白特性就是软件按照设计运行的，问题没有缺陷那么严重。
3.自己解决质量问题
- 没有快速修复缺陷的灵丹妙药，唯一可靠的方法就是修复所有缺陷。 停止开发有缺陷的程序，构建实验，观察结果
- 把不干净的代码从干净的代码中分离出来，如果没有足够的时间修复它，那么就先阻断它，这种方法的一个变化形式是采用“沙箱模型”来解决问题模块。
- 错误分类，定期更新缺陷数据库，并保证新创建项目具有合理的优先级。
- 缺陷闪电战，即在一天、一周或者一个时期内，除了修复缺陷不做其它任何工作，但是要谨慎使用，持续时间一长，很容易让人疲惫，并累垮每一个人。
- 专项小组，是闪电缺陷战的变形，让一个小组在有限的时间内聚集在一起解决特殊的质量问题。
4.修复已经发布的软件时，要集中精力减少风险
- 一个真正的修复可能涉及大范围的软件重构，深层次的软件体系变化，在缺少发布过程的正常检验和各环节平衡的前提下，很难确定其带来的连锁反应，最终使事情变得更糟而不是更好。因此实施一个补丁时，治标不治本可能是一个更好的选择。
- 不要以为修复程序试一次修改就疏忽大意，要注意与这样的修复产生关联的潜在问题，因此要尽可能多的检查。
- 在开发版经历完整的发布周期时，要得到一个完整的、解决根本的修复。
5.向后兼容
- 确定代码本身的修复不会引起兼容性问题，回归测试可以查明向后兼容性问题
- 解决兼容性问题，如果确认导致兼容性问题，那么需要按照下面的选择
- 提供迁移办法
- 实现一个兼容模式
- 提供预警
- 不修复缺陷
6.海森堡缺陷
- 如果在调试器下运行软件，尝试将插桩直接加到源码中。
- 海森堡缺陷依赖于某些不确定性因素，这本身就是一条线索，把你的任务变为寻找某种方法来收集你所需要的信息，这种方法对软件影响极小，保证不会改变它的行为
- 修复该缺陷的唯一办法就是比平时更仔细些，确保你真正了解潜藏的根本原因。
- 在未了解问题本质前，不要假设你已经修复它了。比如缺陷是由一个未出生的变量引起的，那么要弄明白未出生的变量如何引起你观察到的行为？将其初始化为坏值，你能看到预期的结果吗？ 性能缺陷 寻找瓶颈，是哪个特定区域的代码限制了整体性能 准确性能分析
7.嵌入式软件
- 调试嵌入式软件是非常棘手的，不是它错综复杂，而是它所在的运行环境。
- 利用嵌入式调试工具，可以通过网络电缆进行远程调试，或者通过JTAG,SW在线调试,其中挑战之一是软硬件并行发展，通常修复一个硬件问题比解决软件问题更难。
- 提取信息的痛苦过程，一个LCD、LED、串口等手段当做通信通道往往就够了，虽然并不方便，但是它是可能的。
- 利用逻辑分析仪作为软件的调试工具，解决时序错误！
8. 第三方软件的错误
- 不要太快去指责，第三方也只是代码，也会包含缺陷，首先要怀疑自己的代码。
- 如果确信第三方代码存在缺陷，那么出了提交错误报告并等待解决，别无它法，最好是短期内搁置问题。
- 开源代码，很多开源项目只获得了有限的关注，因此其开源不意味着调试的结束。
- 开源社区的一个伟大之处是，为我们提高了高质量、免费的软件，往往高质量的技术支持也是免费的。因此要学会有效的寻求帮助。