记录解决问题的日志（可以利用博客）

将日志保存为可供计算机搜索的格式，可共享大家可一起维护的日志。

记录问题发生日期，问题简述，解决方案详细描述，引用文章或网址，以提供更多细节或相关信息

任何代码片段、设置或对话框的截屏，只要他们是解决方案的一部分，或者可以帮助更深入地理解相关细节。

程序版本、框架版本等等。

 

警告就是错误

将警告视为错误。签入带有警告的代码就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。

签入构建工具的代码不应该产生任何警告信息。，当然无法消除警告也不要浪费时间了

在eclipse中  在preferences中compiler errors/warnings 可以将将警告视为错误处理

 

对问题各个击破

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

首先系统要设计要合理，功能模块化，能迅速定位问题的所在。

 

报告所有异常

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

当出现问题时，心里知道能够得到抛出的异常。而且没有空的异常处理方法，而不是导致程序直接崩溃。

 

提供有用的错误信息

展示有用的错误信息。提供更易于查找错误细节的方式，发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中，

像“无法找到文件”这样无助于问题的解决，“无法打开/ANDY/XXX.YAML以供读取”更为有效。

1.提供用户清晰、易于理解的问题描述和解释

2.提供具备关于错误的详细技术细节给用户，或者可以将其直接发送给技术人员，技术人员能读出错误日志入口的信息。