标签：
简单问题解决思路
可调式环境
查看日志
1。良好的代码，肯定都有异常错误日志，问题简单的话，根据日志直接修改即可
2。良好的日志记录规则，可以直接定位到问题，比如参数错误，业务数据为空等等，如果问题简单可以快速的review并解决
3。无法直接看出问题，需要进一步分析
定位问题，确定大致问题原因
1。根据现象，定位问题，如果简单可直接修改
2。根据异常信息，对象不能为null，除数不能为0等，可以直接分析解决问题简单的review修改
3。根据经验，经验丰富的人对一些见过尤其是偏配置的bug能直接给出解决方案
例如：Unable to make the session state request to the session state server，直接将net的状态服务启动即可
4。逐步查找问题
1。界面加载慢，先看是否是页面本身的问题，例如加载了很多第三方脚本没有响应等
2。查看具体的请求是否响应时间较长
3。请求慢查看业务层调用，处理，是否十分复杂或者代码是否有循环中写的不合理等
例如，循环中直接对比xml等不合理操作
4。如果都没有问题，那么就是数据查询的问题了，往往也就是查询的问题
5。分析查询，
1。查询不合理，sql或存储过程写的不合理，大部分情况如此
2。没有合适的索引，造成全表扫描等，大部分情况如此
例，某个查询数据界面很慢，查找之后定位到了存储过程，分析后发现查询有问题，增加相关索引后基本达标
3。分析执行计划，进行相应优化调整
4。数据量庞大，分析业务是否应该返回这么大的数据量，缓存等其他处理措施，往往庞大的数据量是设计或返回数据不合理
5。其他数据问题及相应处理
6。测试问题是否已经解决或达到性能要求
7。如果已经做了所有的优化可能还不能达到要求，重新信息下业务场景，查看是否有其他好的解决办法，寻求帮助等
5。定位到具体页面，到具体方法，甚至到具体某行某句话为下一步做准备
代码review
1。往往比较怪异的bug或根本无法定位问题，这类问题一般需要靠经验，搜索或寻求帮助来解决
比如还是上面那个net状态服务异常停止的bug
2。大致定位后，直接进行详细的代码review，相对容易的bug还是比较容易查出来并解决
一般自己写的代码自己很难review出来，所以多检查两遍
3。实在查不出，并且没有搜索到相关内容，且没有寻求帮助，这时候就可以借助调试监控查找了
调试
1。大致定位方法，断点单步调试，98%的问题基本就能解决
2。还有一类代码明明没有问题，但是调试的时候甚至会报错，这个时候往往就要换个思路，搜索，寻求帮助
1。比如：之前有个问题调试，直接拖动断电，代码完全没有问题，但是就是报异常，（一个IF判断条件都没有错，注释掉就ok），但就是报空引用异常。（现在也没找到原因，可能是由于拖动断点的问题）
2。还有一类是无法调试的，类似于多线程，服务（当然你可以写个winform的相同程序），这时候基本上只能靠日志，分析，查找，寻求帮助
不可调试环境
查看日志
定位问题
代码review
问题的解决方式基本和上面一样，只不过更需要良好日志的支持，代码分析，经验。
标签：
原文地址：http://www.cnblogs.com/superCow/p/4234637.html
