程序員的生活就是解決一個又一個問題，永無止境。這篇文章介紹了一系列解決問題的策略。

根本的指導方針

1. 首先寫代碼的時候***不要有缺陷。***的修復方法就是讓 bug 胎死腹中。

• 良好的單元測試

• 強制數(shù)據(jù)庫約束

• 使用輸入驗證框架

• 避免未實現(xiàn)的“else”條件

• 在應(yīng)用到主程序之前知道如何在孤立的情況下使用

日志

2. print 語句。往往額外輸出個一兩行將有助于隔離問題。

3. 切換至詳細的日志記錄。詳細的日志記錄有助于發(fā)現(xiàn)更多的線索。

4. 搜索日志。如果日志太多，可采取關(guān)鍵字或錯誤代碼來搜索日志文件。

5. 開啟自動換行和關(guān)閉自動換行。控制日志的自動換行也非常有用。

6. 搜索不同的日志。主服務(wù)器的日志可能并不是唯一有用的日志。

7. Windows 事件日志。日志文件的另一個來源可能是操作系統(tǒng)本身。

8. 制作有用的日志記錄。有時，如果你沒有得到任何有用的日志記錄，那么你可能需要自己寫。

與其他人交流

9. 詢問一些可能知道問題答案的人。

10. 問”愚蠢“的問題。可能你覺得這些問題很愚蠢，但其實并不是。

11. 將問題解釋給隊友。他們可能知道答案或者能提出一些你并沒有想到過的事情。

12. 將問題解釋給你的狗。述說的對象是誰其實沒有關(guān)系，但是能讓你從不同角度分析問題。

寫作

13. 描述問題。用最準確和最精確的語句描述問題，有助于你去思考可能的解決方案。

14. 問題日記。創(chuàng)建一個文本文件來記錄已經(jīng)嘗試的各種方法，包括代碼片段、配置設(shè)置以及產(chǎn)生的任何錯誤。

15. 記錄問題和解決方案。有沒有這樣的情況，突然看到一個似曾相識的問題，只記得解決過但卻忘記了是如何解決的？可以將問題和解決方案記錄到一個容易搜索的地方，如維基、缺陷跟蹤，甚至可以發(fā)送電子郵件給自己。

支持

16. 閱讀 FAQ。

17. 提交支持請求。如果有可用的產(chǎn)品/庫的支持，那么就用。

18. 在你點擊 send 之前，請三思。寫支持請求能讓你再一次思考問題，有時候就在你點擊 send 按鈕之時，突然靈機一動就想到了解決問題的方法或者是新的線索。

19. 其他方面的支持。可以與開發(fā)人員直接面對面交流，***是實時聊天/ SKYPE/屏幕共享。

離開鍵盤

20. 散散步。

21. 打個盹。

22. 重置優(yōu)先級。暫時從鍵盤上離開還有一個好處就是可以讓你重新評估這個問題的重要性，也許這個問題只是個 CSS/布局問題，根本不值得你花上 16 個小時。總之要有效分配和使用時間。

23. 暫時將這個問題放在一邊。實在解決不了的話，可以將這個問題先擱置起來。也許幾天后你在閱讀相關(guān)問題的時候，突然一個激靈，解決問題的關(guān)鍵就來了。

隔離

24. 確定是哪行代碼。首先要確定是哪行代碼導致的問題，以便于插入 print 語句。

25. 將問題分割為一個單獨的程序。有時候?qū)τ趲旌彤a(chǎn)品的問題，我們可以將它的相關(guān)代碼從主程序中分離開來。這可能需要一點時間，但往往處理一個孤立的程序比應(yīng)對整個的項目構(gòu)建過程要容易得多。然后在解決這個單獨程序的基礎(chǔ)上再去和主程序作比較。

更改代碼

即使你一點都不知道如何解決問題，更改代碼也是一個挺有效的解決方法。

26. 寫新的單元測試。

27. 重構(gòu)。有問題的代碼往往顯得有點亂，通過一些簡單的重構(gòu)方法，例如重命名變量或展開嵌套的 if / then/ else 模塊等都可以讓代碼整潔起來。

28. 發(fā)現(xiàn) bug。另一個整潔代碼的手段是查閱相關(guān)代碼的“Find Bugs” 報告，我們之所以首先要整潔代碼是因為：作為一個能讓我們的大腦專注于代碼的方法，既簡單又劃算。

29. 重寫。轉(zhuǎn)存所有的相關(guān)代碼，從頭開始重寫。一個全新的視角也許能讓你完全規(guī)避這個問題。

30. 為一些不必要的代碼添加注釋——或者至少是你以為是不必要的。然后你會發(fā)現(xiàn)可能這些代碼流并不像你曾經(jīng)以為的那樣“沒有必要”。

31. 實驗。如果你不能確定底層產(chǎn)品或庫是如何工作的，那么一些小實驗，特別是圍繞邊界條件的實驗會非常有用。

32. 回到干凈的狀態(tài)。如果你在代碼中做了各種變動，或者是搞了很多配置設(shè)置，那么定期回到一個干凈的狀態(tài)就非常重要。否則，實驗結(jié)果可能會影響正確答案，這樣你就永遠也找不到正確的解決方案了。

33. 切換技術(shù)。

產(chǎn)品

34. 升級到更高的版本。也許你正在處理的問題已經(jīng)被修復了，可以試試先升級到另一個版本。

35. 降級到以前的版本。也許問題正是由于與你目前正在使用的其他產(chǎn)品/庫不兼容而引起的。

36. 打補丁。

37. 下載并安裝源代碼。

文件

38. 閱讀手冊。大多數(shù)開發(fā)人員可能會認為這是一個低概率的策略，但是，嘿嘿，你永遠不知道，也許答案就在文檔中。

39. 閱讀手冊的正確版本。

40. 手冊是否正確？有時候代碼已被更新，但手冊還沒有。

調(diào)試器

41. 了解鍵盤上的快捷鍵。

42. 倒退。這是調(diào)試器的一個功能，讓你的代碼退后一步。

43. 編寫斷點代碼。

44. 異常中斷。調(diào)試器的一個蠻有用的功能就是可以捕捉到任何地方的特定異常。

45. 專業(yè)化的調(diào)試工具。例如：

• Plumbr

• AppDynamics

• Chronon

• Wireshark

• HTTP profilers：Fiddler2、Charles、Live Http Headers

源代碼控制

46. 對 bug 缺陷進行編號標記。你有沒有碰到過這樣的問題：先是用這種方式被修復了，然后幾周后又成為了 bug 被其他人用另一種方法修復了。這樣問題貌似就有兩個正確答案。解決辦法就是對源代碼中相關(guān)的 bug 缺陷進行標記，并記錄一些關(guān)于為何改變以及誰參與決策等更為詳細的說明。

47. Blame 功能。這個可愛的小工具能告訴你是誰***更改的代碼。

48. Git bisect 功能。Git 有一個有意思的“bisect”命令，能自動通過你提交的歷史進行二進制搜索發(fā)現(xiàn)故障。

尋找答案

49. 谷歌搜索。

50. 論壇帖子。

52. 搜索堆棧交流。

53. 創(chuàng)建堆棧問題。

其他

54. 聘請專家。可能在短時間內(nèi)成本很高。

55. 招實習生。聘請專家的相反方法就是聘請新手。有時候初學者飽滿的熱情能讓他們從不同的角度來解決問題。

56. 改變要求。如果你不能修復缺陷，那么可以改變要求。通過解釋各種成本需要，也許能讓客戶改變他們的初衷。

57. 更改上/下游系統(tǒng)。

58. 循序漸進地學習技術(shù)。

59. 通過斷點檢查配置。更改關(guān)鍵配置值，并確保已經(jīng)斷點，這樣能夠讓我們無所顧忌地設(shè)置配置。

60. 系統(tǒng)化。有時候我們需要將三四件事情組合在一起，那么可以將已經(jīng)試過的組合記錄下來，如果需要的話一定要嘗試各種的組合。

英文原文：60 Problem Solving Strategies

中文翻譯：www.geekwww.com