简单问题解决思路

 

 

 

 

 

根据上面的分析，大概总结出来几点

1.80%左右的问题或bug每每是在不可调试的环境下（生产环境）

2.解决问题最笨的方式应该就是调试了。（并且每每问题不可调试）

3.一位童鞋面对bug的反应，必定程度上能反映该童鞋的工做能力。

 

 

 

简单问题解决思路
可调式环境
查看日志
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
问题的解决方式基本和上面同样，只不过更须要良好日志的支持，代码分析，经验。