根本的指導方針
1. 首先寫**的時候最好不要有缺陷。最好的修復方法就是讓 bug 胎死腹中。
日誌
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 模組等都可以讓**整潔起來。
29. 重寫。轉存所有的相關**，從頭開始重寫。乙個全新的視角也許能讓你完全規避這個問題。
30. 為一些不必要的**新增注釋——或者至少是你以為是不必要的。然後你會發現可能這些**流並不像你曾經以為的那樣「沒有必要」。
31. 實驗。如果你不能確定底層產品或庫是如何工作的，那麼一些小實驗，特別是圍繞邊界條件的實驗會非常有用。
32. 回到乾淨的狀態。如果你在**中做了各種變動，或者是搞了很多配置設定，那麼定期回到乙個乾淨的狀態就非常重要。否則，實驗結果可能會影響正確答案，這樣你就永遠也找不到正確的解決方案了。
33. 切換技術。
產品
34. 公升級到更高的版本。也許你正在處理的問題已經被修復了，可以試試先公升級到另乙個版本。
35. 降級到以前的版本。也許問題正是由於與你目前正在使用的其他產品/庫不相容而引起的。
36. 打補丁。
檔案
38. 閱讀手冊。大多數開發人員可能會認為這是乙個低概率的策略，但是，嘿嘿，你永遠不知道，也許答案就在文件中。
39. 閱讀手冊的正確版本。
40. 手冊是否正確？有時候**已被更新，但手冊還沒有。
偵錯程式
41. 了解鍵盤上的快捷鍵。
42. 倒退。這是偵錯程式的乙個功能，讓你的**退後一步。
43. 編寫斷點**。
44. 異常中斷。偵錯程式的乙個蠻有用的功能就是可以捕捉到任何地方的特定異常。
45. 專業化的除錯工具。例如：
源**控制
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
中文翻譯：www.geekwww.com
PHP 程式設計師解決問題能力的6個級別
參考 青銅 var dump die列印變數值資訊單步除錯 是最簡單粗暴有效的解決問題方法。高階一點的是使用列印日誌。會設定各種錯誤日誌的記錄和顯示，並根據各種錯誤日誌分析錯誤或者搜尋別人的解決方案 php.ini 設定錯誤記錄 display errors on error reporting e...
關於PHP程式設計師解決問題的能力
這個話題老生長談了，在面試中必然考核的能力中，我個人認為解決問題能力是排第一位的，比學習能力優先順序更高。解決問題的能力既能看出程式設計師的思維能力，應變能力，探索能力等，又可以看出他的經驗。如果解決問題能力不佳是無法通過面試的。這裡舉個例子，假如我執行了乙個php的指令碼，如php test.ph...
關於PHP程式設計師解決問題的能力
假如我執行了乙個php的指令碼，如php test.php，預期是可以返回乙個字串。但執行後沒有任何資訊輸出，這時候通過什麼方法能知道程式錯在 這裡可以將解決問題能力分為8個等級，越到後面的表示能力越強。lv0 檢視php錯誤資訊 程式沒有達到預期效果，證明 出錯了，看php的錯誤資訊是第一步。如果...