- 记录问题解决日志
- 告警就是错误
- 对问题各个击破
- 报告所有的异常
- 提供有用的错误信息
记录问题解决日志
可以选择符合需求的任何格式。下面这些条目可能会用得上。
- 问题发生日期。
- 问题简述。
- 解决方案详细描述。
- 引用文章或网址，以提供更多细节或相关信息。
- 任何代码片段、设置或对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。
要记录团队做出一个重要决策的原因。否则，在6~9个月之后，想再重新回顾决策过程的时候，这些细节就很难再记得了，很容易发生互相指责的情形。
警告就是错误
将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
对问题各个击破
在解决问题时，要将问题域与其周边隔离开来，特别是在大型应用中。
单元测试的好处之一，是它会强迫形成代码的分层。因为要保证代码的可测试，就必须把它从周边代码中解脱出来。
识别复杂问题的第一步，是将它们分离出来。就像试图修复正在飞行的飞机的引擎，但是当引擎被从飞机中取出来，而且放在工作台上之后，修复就变得容易了。同理，如何可以隔离出发生问题的模块，也更容易修复发生问题的代码。
隔离问题不应该只在交付软件之后才着手。在构建系统原型、调试和测试时，各个击破的战略都可以起到帮助作用。
报告所有异常
有一条新闻，提到一套大型航空订票系统中发生了严重的问题。系统崩溃，飞机停飞，上千名旅客滞留机场，整个航空运输系统数天之内都乱作一团。原因是什么？在一台应用服务器上发生了一个未检查异常。
处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题
决定由谁来负责处理异常是设计工作的一部分。
不是所有的问题都应该抛出异常。
报告的异常应该在代码的上下文中有实际意义。
要传播不能处理的异常。
提供有用的错误信息
一方面提供给用户清晰、易于理解的问题描述和解释，使他们有可能寻求变通之法。另一方面，还要提供具备关于错误的详细技术细节给用户，这样方便开发人员寻找代码中真正的问题所在。
错误类型：
- 程序缺陷，即系统的bug，需要修复代码才能解决；
- 环境问题，如数据库连接失败、磁盘容量不足、权限不足，系统管理员可以解决此类问题；
- 用户错误，用户操作问题，告诉用户
像“无法找到文件”这样的错误信息，就其本身而言无助于问题的解决。“无法打开/andy/project/main.yaml以供读取”这样的信息更有效。
在提供更多信息的同时，不要泄露安全信息、个人隐私、商业机密，或其他敏感信息（对于基于Web的应用，这一点尤其重要）。
