高效程序的45个习惯---第七章 敏捷调试

33 记录问题解决日志

 

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

 

解决方案日志应该作为思考的一个来源，可以在基中发现某些特定问题的细节。对某些类似但是有差异的问题，也能从中获得修复的指引。

 

平衡的艺术

 

1 记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单，不必达到对外发布式的质量。

2 找到以前的解决方法非常关键。使用足够的关键字，可以帮助你在需要的时候发现需要的条目。

3 如果通过搜索Web，发现没有曾经遇到同样的问题，也许搜索的方式有问题。

4 要记录发生问题时应用程序，应用框架或平台的特定版本。同样的问题在不同的平台或版本上可能表现得不同。

5 要记录团队做出一个重要决策的原因。否则，在6~9个月之后，想再重新回顾决策过程的时候，这些细节就很难再记得了，很容易发生互相指责的情形。

 

 

34 警告就是错误

 

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

 

 

平衡的艺术

 

1 虽然这里探讨的主要是编译语言，解释型语言通常也有标志，允许运行时警告。

2 由于编译器的bug或者第三方工具或是代码的原因，有些警告无法消除。如果确实没有应对之衙内的话，就不要再浪费更多时间了。但是类似的状况很少发生。

3 应该经常指示编译器：要特别注意别将无法避免的警告作为错误进行提示。这样就不用费力去查看所有的提示，以找到真正的错误和警告。

4 弃用的方法被弃用是有原因的。不要再使用它们了，至少，安排一个迭代来将它们安全地移除掉。

5 如果将过去开发完成的方法标记为弃用方法，要记录当前用户应该采取何种变通之策，以及被弃用的方法将会在何时一起移除。

 

35 对问题各个击破

 

平衡的艺术

 

1 如果将代码从其运行环境中分离后，问题消失不见了，这有助于隔离问题。

2 另一方面，如果将代码从其运行环境中分离后，问题还在，这也有助于隔离问题。

3 以二分查找的方式来定位问题是有很用的。也就是说，将问题空间分为两半，看看哪一半包含问题。再将包含问题的一半进行二分，并不断重复这个过程。

4 在向问题发起攻击之前，先查找你的问题解决日志。

 

36 报告所有的异常

 

处理或是向上传播所有的异常，不要将它们压制不管，就是算是临时这样做也不行。在写代码时要估计到会发生的问题。

 

平衡的艺术

 

1 决定由谁来负责处理异常是设计工作的一部分。

2 不是所有的问题都应该抛出异常。

3 报告的异常应该在代码的上下文中有实际意义。

4 如果代码中会记录运行时调试日志，当捕获或是抛出异常时，都要记录日志信息：这样做对以后的跟踪工作很帮助。

5 检查异常处理起来很麻烦，没人意愿调用抛出31种不同检查异常的方法。这是调试上的问题：要把它解决掉，而不是随便打个补丁就算了。

6 要传播不能处理的异常。

 

37 提供有用的错误信息

 

1 像“无法找到文件”这样的错误 信息，就其本身而言无助于问题的解决。“无法打开XXXX以供读取”，这样的信息更有效。

2 没有必要等待抛出异常来发现问题，在代码关键点使用断言以保证一切正常。当断言失败时，要提供与异常报告同样详细的信息。