敏捷开发修炼之道 （四）敏捷调试、敏捷协作

第7章：敏捷调试

记录解决问题的日志。

警告就是错误。

对于问题各个击破。

报告所有异常。

提供有用的错误信息。

记录问题解决日志

不要在同一处跌倒两次。

每日日志

1. 问题发生日期。
2. 问题简述。
3. 解决方案详细描述。
4. 引用文章或网址，以提供更多细节或相关信息。
5. 任何代码片段、设置或对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。

维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。

平衡的艺术

1. 记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单，不必达到对外发布式的质量。
2. 找到以前的解决方法非常关键。使用足够的关键字，可以帮助你在需要的时候发现需要的条目。
3. 如果通过搜索Web，发现没人曾经遇到同样的问题，也许搜索的方式有问题。
4. 要记录发生问题时应用程序、应用框架或平台的特定版本。同样的问题在不同的平台或版本上可能表现得不同。
5. 要记录团队做出一个重要决策的原因。否则，在6~9个月之后，想再重新回顾决策过程的时候，这些细节就很难再记得了，很容易发生互相指责的情形。

警告就是错误

将警告视为错误。签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。

平衡的艺术

1. 虽然这里探讨的主要是编译语言，解释型语言通常也有标志，允许运行时警告。使用相关标志，然后捕获输出，以识别并最终消除警告。
2. 由于编译器的bug或是第三方工具或代码的原因，有些警告无法消除。如果确实没有应对之策的话，就不要再浪费更多时间了，但是类似的状况根少发生。
3. 应该经常指示编译器：要特别注意别将无法避免的警告作为错误进行提示，这样就不用费力去查看所有的提示，以找到真正的错误和警告。
4. 弃用的方法被弃用是有原因的。不要再使用它们了。至少，安排一个迭代来将它们（以及它们引起的警告信息)安全地移除掉。
5. 如果将过去开发完成的方法标记为弃用方法，要记录当前用户应该采取何种变通之策,以及被弃用的方法将会在何时一起移除。

对问题各个击破

可以先使用调试器，逐行执行代码，并试图隔离问题。

用原型进行分离：识别复杂问题的第一步，是将它们分离出来。