1.首先寫程式碼的時候最好不要有缺陷。最好的修復方法就是讓bug胎死腹中。
- 良好的單元測試
- 強制資料庫約束
- 使用輸入驗證框架
- 避免未實現的“else”條件
- 在應用到主程式之前知道如何在孤立的情況下使用
日誌
2.print語句。往往額外輸出個一兩行將有助於隔離問題。
3.切換至詳細的日誌記錄。詳細的日誌記錄有助於發現更多的線索。
4.搜尋日誌。如果日誌太多，可採取關鍵字或錯誤程式碼來搜尋日誌檔案。
5.開啟自動換行和關閉自動換行。控制日誌的自動換行也非常有用。
6.搜尋不同的日誌。主伺服器的日誌可能並不是唯一有用的日誌。
7.Windows事件日誌。日誌檔案的另一個來源可能是作業系統本身。
8.製作有用的日誌記錄。有時，如果你沒有得到任何有用的日誌記錄，那麼你可能需要自己寫。
與其他人交流
9.詢問一些可能知道問題答案的人。
10.問”愚蠢“的問題。可能你覺得這些問題很愚蠢，但其實並不是。
11.將問題解釋給隊友。他們可能知道答案或者能提出一些你並沒有想到過的事情。
12.將問題解釋給你的狗。述說的物件是誰其實沒有關係，但是能讓你從不同角度分析問題。
寫作
13.描述問題。用最準確和最精確的語句描述問題，有助於你去思考可能的解決方案。
14.問題日記。建立一個文字檔案來記錄已經嘗試的各種方法，包括程式碼片段、配置設定以及產生的任何錯誤。
15.記錄問題和解決方案。有沒有這樣的情況，突然看到一個似曾相識的問題，只記得解決過但卻忘記了是如何解決的？可以將問題和解決方案記錄到一個容易搜尋的地方，如維基、缺陷跟蹤，甚至可以傳送電子郵件給自己。
支援
16.閱讀FAQ。
17.提交支援請求。如果有可用的產品/庫的支援，那麼就用。
18.在你點選send之前，請三思。寫支援請求能讓你再一次思考問題，有時候就在你點選send按鈕之時，突然靈機一動就想到了解決問題的方法或者是新的線索。
19.其他方面的支援。可以與開發人員直接面對面交流，最好是實時聊天/ SKYPE/螢幕共享。
離開鍵盤
20.散散步。
21.打個盹。
22.重置優先順序。暫時從鍵盤上離開還有一個好處就是可以讓你重新評估這個問題的重要性，也許這個問題只是個CSS/佈局問題，根本不值得你花上16個小時。總之要有效分配和使用時間。
23.暫時將這個問題放在一邊。實在解決不了的話，可以將這個問題先擱置起來。也許幾天後你在閱讀相關問題的時候，突然一個激靈，解決問題的關鍵就來了。
隔離
24.確定是哪行程式碼。首先要確定是哪行程式碼導致的問題，以便於插入print語句。
25.將問題分割為一個單獨的程式。有時候對於庫和產品的問題，我們可以將它的相關程式碼從主程式中分離開來。這可能需要一點時間，但往往處理一個孤立的程式比應對整個的專案構建過程要容易得多。然後在解決這個單獨程式的基礎上再去和主程式作比較。
更改程式碼
即使你一點都不知道如何解決問題，更改程式碼也是一個挺有效的解決方法。
26.寫新的單元測試。
27.重構。有問題的程式碼往往顯得有點亂，通過一些簡單的重構方法，例如重新命名變數或展開巢狀的if / then/ else模組等都可以讓程式碼整潔起來。
28.發現bug。另一個整潔程式碼的手段是查閱相關程式碼的“Find Bugs” 報告，我們之所以首先要整潔程式碼是因為：作為一個能讓我們的大腦專注於程式碼的方法，既簡單又划算。
29.重寫。轉存所有的相關程式碼，從頭開始重寫。一個全新的視角也許能讓你完全規避這個問題。
30.為一些不必要的程式碼新增註釋——或者至少是你以為是不必要的。然後你會發現可能這些程式碼流並不像你曾經以為的那樣“沒有必要”。
31.實驗。如果你不能確定底層產品或庫是如何工作的，那麼一些小實驗，特別是圍繞邊界條件的實驗會非常有用。
32.回到乾淨的狀態。如果你在程式碼中做了各種變動，或者是搞了很多配置設定，那麼定期回到一個乾淨的狀態就非常重要。否則，實驗結果可能會影響正確答案，這樣你就永遠也找不到正確的解決方案了。
33.切換技術。
產品
34.升級到更高的版本。也許你正在處理的問題已經被修復了，可以試試先升級到另一個版本。
35.降級到以前的版本。也許問題正是由於與你目前正在使用的其他產品/庫不相容而引起的。
36.打補丁。
37.下載並安裝原始碼。
檔案
38.閱讀手冊。大多數開發人員可能會認為這是一個低概率的策略，但是，嘿嘿，你永遠不知道，也許答案就在文件中。
39.閱讀手冊的正確版本。
40.手冊是否正確？有時候程式碼已被更新，但手冊還沒有。
偵錯程式
41.瞭解鍵盤上的快捷鍵。
42.倒退。這是偵錯程式的一個功能，讓你的程式碼退後一步。
43.編寫斷點程式碼。
44.異常中斷。偵錯程式的一個蠻有用的功能就是可以捕捉到任何地方的特定異常。
45.專業化的除錯工具。例如：
- Plumbr
- AppDynamics
- Chronon
- Wireshark
- HTTP profilers：Fiddler2、Charles、Live Http Headers
原始碼控制
46.對bug缺陷進行編號標記。你有沒有碰到過這樣的問題：先是用這種方式被修復了，然後幾周後又成為了bug被其他人用另一種方法修復了。這樣問題貌似就有兩個正確答案。解決辦法就是對原始碼中相關的bug缺陷進行標記，並記錄一些關於為何改變以及誰參與決策等更為詳細的說明。
47.Blame功能。這個可愛的小工具能告訴你是誰最後更改的程式碼。
48.Git bisect功能。Git有一個有意思的“bisect”命令，能自動通過你提交的歷史進行二進位制搜尋發現故障。
尋找答案
49.谷歌搜尋。
50.論壇帖子。
52.搜尋堆疊交流。
53.建立堆疊問題。
其他
54.聘請專家。可能在短時間內成本很高。
55.招實習生。聘請專家的相反方法就是聘請新手。有時候初學者飽滿的熱情能讓他們從不同的角度來解決問題。
56.改變要求。如果你不能修復缺陷，那麼可以改變要求。通過解釋各種成本需要，也許能讓客戶改變他們的初衷。
57.更改上/下游系統。
58.循序漸進地學習技術。
59.通過斷點檢查配置。更改關鍵配置值，並確保已經斷點，這樣能夠讓我們無所顧忌地設定配置。
60.系統化。有時候我們需要將三四件事情組合在一起，那麼可以將已經試過的組合記錄下來，如果需要的話一定要嘗試各種的組合。
英文原文：60 Problem Solving Strategies
翻譯作者：極客網 – Lili
相關閱讀
評論(1)