簡單問題解決思路

 

 

 

 

 

根據上面的分析，大概總結出來幾點

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
問題的解決方式基本和上面同樣，只不過更須要良好日誌的支持，代碼分析，經驗。