2020.05.20软件构造听课笔记

断言和异常处理都可以处理同样的错误
开发阶段用断言尽可能消除bugs
在发行版本里用异常处理机制处理漏掉的错误

对于来自外部的数据源要仔细检查，例如：文件、网络数据、用户输入等

Barricade：

类的public方法接收到的外部数据都应该被认为是dirty的，需要处理干净再传递到private方法——隔离舱

隔离舱外部的函数应该使用异常处理，隔离舱内的函数应该使用断言处理

增加了复杂性、运行时间和维护成本
防御性代码本身也有可能存在缺陷
设计好如何进行防御，制定相应的防御策略

Debug的目的是寻求错误的根源并消除它
Debug占用了大量的开发时间

Debug是测试的后续步骤：测试发现问题，debug消除问题
在不正常症状与原因之间建立联系，通过回归测试判定bug是否已被解决

症状和原因可能相隔很远，高耦合导致的结果
当其他bug被修复后，该bug消失了
因为人工错误导致的bug的症状难以有效追踪

有些症状是由计时/定时等时间原因导致的
难以复现出错时的输入数据
由于外部软硬件环境变化，导致间歇性的症状
分布式导致的问题

错误定位占据了绝大部分的调试时间
研究问题：自动化错误定位

常用方法：假设——检验
收集bug相关数据
观察数据，做出bug原因的假设
决定如何验证
通过工具验证假设是否成立

从最小的测试用例集开始复现错误

确定有哪些因素跟bug相关，将这些因素找出来并变化它们的值
确保你的bug复现环境跟用户发现bug的环境尽可能保持一致

策略：
1.插桩代码，不影响软件的行为，提供对软件行为的深入了解
2.分治：防狼围栏算法
3.切片：
4.寻找差异：充分利用版本控制系统，找出在哪个commit之后出现了bug症状
5.基于差异测试的调试：两个测试用例，分别通过/未通过，通过查找二者所覆盖代码之间的差异，快速定位出可能造成bug的代码行
6.调试器：
7.learn from others

debug的方法：
debugging by Brute Force暴力！（看导出文件，到处println()，自动化调试工具）

print：
一旦软件对外发布，所有用于debug的print语句都要去除或禁用

Logging（日志技术）：
通过设定日志级别来确定要log哪些信息
log结果可被多种渠道加以处理，可通过设定条件进行过滤，并输出为多种格式
可以使用层次化的多个日志记录器

针对一个应用，为其设定全局的logger
使用全局logger导致信息混乱，需要定义自己的logger

设定不同的日志级别：
设定日志级别，高于该级别的日志才会被记录

缺省：输出到控制台
日志处理器也需要设置日志级别
日志处理器：记录的日志会被传送到什么地方加以展示/储存/处理

除了ConsoleHandler，还可以设定其他的handlers