南順網絡

程序員解決問題的(de)60個策略

根本的(de)指導方針

1. 首先寫代碼的(de)時候最好不要有缺陷。最好的(de)修複方法就是讓 bug 胎死腹中。

• 良好的(de)單元測試

• 強制數據庫約束

• 使用輸入驗證框架

• 避免未實現的(de)“else”條件

• 在應用到主程序之前知道(dào)如(rú)何在孤立的(de)情況下使用

日志

2. print 語句。往往額外輸出個一(yī)兩行将有助于隔離(lí)問題。

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

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

5. 開啓自(zì)動換行和(hé)關閉自(zì)動換行。控制日志的(de)自(zì)動換行也非常有用。

6. 搜索不同的(de)日志。主服務器的(de)日志可(kě)能并不是唯一(yī)有用的(de)日志。

7. Windows 事件日志。日志文件的(de)另一(yī)個來源可(kě)能是操作系統本身。

8. 制作有用的(de)日志記錄。有時，如(rú)果你沒有得到任何有用的(de)日志記錄，那麽你可(kě)能需要自(zì)己寫。

與其他人交流

9. 詢問一(yī)些可(kě)能知道(dào)問題答案的(de)人。

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

11. 将問題解釋給隊友。他們可(kě)能知道(dào)答案或者能提出一(yī)些你并沒有想到過的(de)事情。

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

寫作

13. 描述問題。用最準确和(hé)最精确的(de)語句描述問題，有助于你去(qù)思考可(kě)能的(de)解決方案。

14. 問題日記。創建一(yī)個文本文件來記錄已經嘗試的(de)各種方法，包括代碼片段、配置設置以及産生的(de)任何錯誤。

15. 記錄問題和(hé)解決方案。有沒有這樣的(de)情況，突然看到一(yī)個似曾相識的(de)問題，隻記得解決過但卻忘記了是如(rú)何解決的(de)？可(kě)以将問題和(hé)解決方案記錄到一(yī)個容易搜索的(de)地(dì)方，如(rú)維基、缺陷跟蹤，甚至可(kě)以發送電子(zǐ)郵件給自(zì)己。

支持

16. 閱讀 FAQ。

17. 提交支持請求。如(rú)果有可(kě)用的(de)産品/庫的(de)支持，那麽就用。

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

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

離(lí)開鍵盤

20. 散散步。

21. 打個盹。

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

23. 暫時将這個問題放在一(yī)邊。實在解決不了的(de)話，可(kě)以将這個問題先擱置起來。也許幾天後你在閱讀相關問題的(de)時候，突然一(yī)個激靈，解決問題的(de)關鍵就來了。

隔離(lí)

24. 确定是哪行代碼。首先要确定是哪行代碼導緻的(de)問題，以便于插入 print 語句。

25. 将問題分割為(wèi)一(yī)個單獨的(de)程序。有時候對于庫和(hé)産品的(de)問題，我們可(kě)以将它的(de)相關代碼從主程序中分離(lí)開來。這可(kě)能需要一(yī)點時間，但往往處理(lǐ)一(yī)個孤立的(de)程序比應對整個的(de)項目構建過程要容易得多。然後在解決這個單獨程序的(de)基礎上再去(qù)和(hé)主程序作比較。

更改代碼

即使你一(yī)點都不知道(dào)如(rú)何解決問題，更改代碼也是一(yī)個挺有效的(de)解決方法。

26. 寫新的(de)單元測試。

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

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

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

30. 為(wèi)一(yī)些不必要的(de)代碼添加注釋——或者至少是你以為(wèi)是不必要的(de)。然後你會發現可(kě)能這些代碼流并不像你曾經以為(wèi)的(de)那樣“沒有必要”。

31. 實驗。如(rú)果你不能确定底層産品或庫是如(rú)何工作的(de)，那麽一(yī)些小實驗，特别是圍繞邊界條件的(de)實驗會非常有用。

32. 回到幹淨的(de)狀态。如(rú)果你在代碼中做(zuò)了各種變動，或者是搞了很多配置設置，那麽定期回到一(yī)個幹淨的(de)狀态就非常重要。否則，實驗結果可(kě)能會影響正确答案，這樣你就永遠也找不到正确的(de)解決方案了。

33. 切換技術。

産品

34. 升級到更高(gāo)的(de)版本。也許你正在處理(lǐ)的(de)問題已經被修複了，可(kě)以試試先升級到另一(yī)個版本。

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

36. 打補丁。

37. 下載并安裝源代碼。

文件

38. 閱讀手冊。大多數開發人員可(kě)能會認為(wèi)這是一(yī)個低(dī)概率的(de)策略，但是，嘿嘿，你永遠不知道(dào)，也許答案就在文檔中。

39. 閱讀手冊的(de)正确版本。

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

調試器

41. 了解鍵盤上的(de)快捷鍵。

42. 倒退。這是調試器的(de)一(yī)個功能，讓你的(de)代碼退後一(yī)步。

43. 編寫斷點代碼。

44. 異常中斷。調試器的(de)一(yī)個蠻有用的(de)功能就是可(kě)以捕捉到任何地(dì)方的(de)特定異常。

45. 專業化的(de)調試工具。例如(rú)：

• Plumbr

• AppDynamics

• Chronon

• Wireshark

• HTTP profilers：Fiddler2、Charles、Live Http Headers

源代碼控制

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

47. Blame 功能。這個可(kě)愛的(de)小工具能告訴你是誰最後更改的(de)代碼。

48. Git bisect 功能。Git 有一(yī)個有意思的(de)“bisect”命令，能自(zì)動通過你提交的(de)曆史進行二進制搜索發現故障。

尋找答案

49. 谷歌搜索。

50. 論壇帖子(zǐ)。

52. 搜索堆棧交流。

53. 創建堆棧問題。

其他

54. 聘請專家。可(kě)能在短(duǎn)時間內(nèi)成本很高(gāo)。

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

56. 改變要求。如(rú)果你不能修複缺陷，那麽可(kě)以改變要求。通過解釋各種成本需要，也許能讓客戶改變他們的(de)初衷。

57. 更改上/下遊系統。

58. 循序漸進地(dì)學(xué)習技術。

59. 通過斷點檢查配置。更改關鍵配置值，并确保已經斷點，這樣能夠讓我們無所顧忌地(dì)設置配置。

60. 系統化。有時候我們需要将三四件事情組合在一(yī)起，那麽可(kě)以将已經試過的(de)組合記錄下來，如(rú)果需要的(de)話一(yī)定要嘗試各種的(de)組合。

編輯:--ns868