高效程序员的45个习惯 7.敏捷调试

• 记录问题解决日志
• 告警就是错误
• 对问题各个击破
• 报告所有的异常
• 提供有用的错误信息

记录问题解决日志

可以选择符合需求的任何格式。下面这些条目可能会用得上。

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

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

警告就是错误

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

对问题各个击破

在解决问题时，要将问题域与其周边隔离开来，特别是在大型应用中。

单元测试的好处之一，是它会强迫形成代码的分层。因为要保证代码的可测试，就必须把它从周边代码中解脱出来。

识别复杂问题的第一步，是将它们分离出来。就像试图修复正在飞行的飞机的引擎，但是当引擎被从飞机中取出来，而且放在工作台上之后，修复就变得容易了。同理，如何可以隔离出发生问题的模块，也更容易修复发生问题的代码。

隔离问题不应该只在交付软件之后才着手。在构建系统原型、调试和测试时，各个击破的战略都可以起到帮助作用。

报告所有异常

有一条新闻，提到一套大型航空订票系统中发生了严重的问题。系统崩溃，飞机停飞，上千名旅客滞留机场，整个航空运输系统数天之内都乱作一团。原因是什么？在一台应用服务器上发生了一个未检查异常。

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

决定由谁来负责处理异常是设计工作的一部分。
不是所有的问题都应该抛出异常。
报告的异常应该在代码的上下文中有实际意义。
要传播不能处理的异常。

提供有用的错误信息

一方面提供给用户清晰、易于理解的问题描述和解释，使他们有可能寻求变通之法。另一方面，还要提供具备关于错误的详细技术细节给用户，这样方便开发人员寻找代码中真正的问题所在。

错误类型：

• 程序缺陷，即系统的bug，需要修复代码才能解决；
• 环境问题，如数据库连接失败、磁盘容量不足、权限不足，系统管理员可以解决此类问题；
• 用户错误，用户操作问题，告诉用户

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

在提供更多信息的同时，不要泄露安全信息、个人隐私、商业机密，或其他敏感信息（对于基于Web的应用，这一点尤其重要）。