程序員的生活就是解決一個(gè)又一個(gè)問(wèn)題，永無(wú)止境。這篇文章介紹了一系列解決問(wèn)題的策略。
根本的指導方針
1. 首先寫(xiě)代碼的時(shí)候最好不要有缺陷。最好的修復方法就是讓 bug 胎死腹中。
良好的單元測試
強制數據庫約束
使用輸入驗證框架
避免未實(shí)現的“else”條件
在應用到主程序之前知道如何在孤立的情況下使用
日志
2. print 語(yǔ)句。往往額外輸出個(gè)一兩行將有助于隔離問(wèn)題。
3. 切換至詳細的日志記錄。詳細的日志記錄有助于發(fā)現更多的線(xiàn)索。
4. 搜索日志。如果日志太多，可采取關(guān)鍵字或錯誤代碼來(lái)搜索日志文件。
5. 開(kāi)啟自動(dòng)換行和關(guān)閉自動(dòng)換行?？刂迫罩镜淖詣?dòng)換行也非常有用。
6. 搜索不同的日志。主服務(wù)器的日志可能并不是唯一有用的日志。
7. Windows 事件日志。日志文件的另一個(gè)來(lái)源可能是操作系統本身。
8. 制作有用的日志記錄。有時(shí)，如果你沒(méi)有得到任何有用的日志記錄，那么你可能需要自己寫(xiě)。
與其他人交流
9. 詢(xún)問(wèn)一些可能知道問(wèn)題答案的人。
10. 問(wèn)”愚蠢“的問(wèn)題?？赡苣阌X(jué)得這些問(wèn)題很愚蠢，但其實(shí)并不是。
11. 將問(wèn)題解釋給隊友。他們可能知道答案或者能提出一些你并沒(méi)有想到過(guò)的事情。
12. 將問(wèn)題解釋給你的狗。述說(shuō)的對象是誰(shuí)其實(shí)沒(méi)有關(guān)系，但是能讓你從不同角度分析問(wèn)題。
寫(xiě)作
13. 描述問(wèn)題。用最準確和最精確的語(yǔ)句描述問(wèn)題，有助于你去思考可能的解決方案。
14. 問(wèn)題日記。創(chuàng )建一個(gè)文本文件來(lái)記錄已經(jīng)嘗試的各種方法，包括代碼片段、配置設置以及產(chǎn)生的任何錯誤。
15. 記錄問(wèn)題和解決方案。有沒(méi)有這樣的情況，突然看到一個(gè)似曾相識的問(wèn)題，只記得解決過(guò)但卻忘記了是如何解決的？可以將問(wèn)題和解決方案記錄到一個(gè)容易搜索的地方，如維基、缺陷跟蹤，甚至可以發(fā)送電子郵件給自己。
支持
16. 閱讀 FAQ。
17. 提交支持請求。如果有可用的產(chǎn)品/庫的支持，那么就用。
18. 在你點(diǎn)擊 send 之前，請三思。寫(xiě)支持請求能讓你再一次思考問(wèn)題，有時(shí)候就在你點(diǎn)擊 send 按鈕之時(shí)，突然靈機一動(dòng)就想到了解決問(wèn)題的方法或者是新的線(xiàn)索。
19. 其他方面的支持?？梢耘c開(kāi)發(fā)人員直接面對面交流，最好是實(shí)時(shí)聊天/ SKYPE/屏幕共享。
離開(kāi)鍵盤(pán)
20. 散散步。
21. 打個(gè)盹。
22. 重置優(yōu)先級。暫時(shí)從鍵盤(pán)上離開(kāi)還有一個(gè)好處就是可以讓你重新評估這個(gè)問(wèn)題的重要性，也許這個(gè)問(wèn)題只是個(gè) CSS/布局問(wèn)題，根本不值得你花上 16 個(gè)小時(shí)?？傊行Х峙浜褪褂脮r(shí)間。
23. 暫時(shí)將這個(gè)問(wèn)題放在一邊。實(shí)在解決不了的話(huà)，可以將這個(gè)問(wèn)題先擱置起來(lái)。也許幾天后你在閱讀相關(guān)問(wèn)題的時(shí)候，突然一個(gè)激靈，解決問(wèn)題的關(guān)鍵就來(lái)了。
隔離
24. 確定是哪行代碼。首先要確定是哪行代碼導致的問(wèn)題，以便于插入 print 語(yǔ)句。
25. 將問(wèn)題分割為一個(gè)單獨的程序。有時(shí)候對于庫和產(chǎn)品的問(wèn)題，我們可以將它的相關(guān)代碼從主程序中分離開(kāi)來(lái)。這可能需要一點(diǎn)時(shí)間，但往往處理一個(gè)孤立的程序比應對整個(gè)的項目構建過(guò)程要容易得多。然后在解決這個(gè)單獨程序的基礎上再去和主程序作比較。
更改代碼
即使你一點(diǎn)都不知道如何解決問(wèn)題，更改代碼也是一個(gè)挺有效的解決方法。
26. 寫(xiě)新的單元測試。
27. 重構。有問(wèn)題的代碼往往顯得有點(diǎn)亂，通過(guò)一些簡(jiǎn)單的重構方法，例如重命名變量或展開(kāi)嵌套的 if / then/ else 模塊等都可以讓代碼整潔起來(lái)。
28. 發(fā)現 bug。另一個(gè)整潔代碼的手段是查閱相關(guān)代碼的“Find Bugs” 報告，我們之所以首先要整潔代碼是因為：作為一個(gè)能讓我們的大腦專(zhuān)注于代碼的方法，既簡(jiǎn)單又劃算。
29. 重寫(xiě)。轉存所有的相關(guān)代碼，從頭開(kāi)始重寫(xiě)。一個(gè)全新的視角也許能讓你完全規避這個(gè)問(wèn)題。
30. 為一些不必要的代碼添加注釋——或者至少是你以為是不必要的。然后你會(huì )發(fā)現可能這些代碼流并不像你曾經(jīng)以為的那樣“沒(méi)有必要”。
31. 實(shí)驗。如果你不能確定底層產(chǎn)品或庫是如何工作的，那么一些小實(shí)驗，特別是圍繞邊界條件的實(shí)驗會(huì )非常有用。
32. 回到干凈的狀態(tài)。如果你在代碼中做了各種變動(dòng)，或者是搞了很多配置設置，那么定期回到一個(gè)干凈的狀態(tài)就非常重要。否則，實(shí)驗結果可能會(huì )影響正確答案，這樣你就永遠也找不到正確的解決方案了。
33. 切換技術(shù)。
產(chǎn)品
34. 升級到更高的版本。也許你正在處理的問(wèn)題已經(jīng)被修復了，可以試試先升級到另一個(gè)版本。
35. 降級到以前的版本。也許問(wèn)題正是由于與你目前正在使用的其他產(chǎn)品/庫不兼容而引起的。
36. 打補丁。
37. 下載并安裝源代碼。
文件
38. 閱讀手冊。大多數開(kāi)發(fā)人員可能會(huì )認為這是一個(gè)低概率的策略，但是，嘿嘿，你永遠不知道，也許答案就在文檔中。
39. 閱讀手冊的正確版本。
40. 手冊是否正確？有時(shí)候代碼已被更新，但手冊還沒(méi)有。
調試器
41. 了解鍵盤(pán)上的快捷鍵。
42. 倒退。這是調試器的一個(gè)功能，讓你的代碼退后一步。
43. 編寫(xiě)斷點(diǎn)代碼。
44. 異常中斷。調試器的一個(gè)蠻有用的功能就是可以捕捉到任何地方的特定異常。
45. 專(zhuān)業(yè)化的調試工具。例如：
Plumbr
AppDynamics
Chronon
Wireshark
HTTP profilers：Fiddler2、Charles、Live Http Headers
源代碼控制
46. 對 bug 缺陷進(jìn)行編號標記。你有沒(méi)有碰到過(guò)這樣的問(wèn)題：先是用這種方式被修復了，然后幾周后又成為了 bug 被其他人用另一種方法修復了。這樣問(wèn)題貌似就有兩個(gè)正確答案。解決辦法就是對源代碼中相關(guān)的 bug 缺陷進(jìn)行標記，并記錄一些關(guān)于為何改變以及誰(shuí)參與決策等更為詳細的說(shuō)明。
47. Blame 功能。這個(gè)可愛(ài)的小工具能告訴你是誰(shuí)最后更改的代碼。
48. Git bisect 功能。Git 有一個(gè)有意思的“bisect”命令，能自動(dòng)通過(guò)你提交的歷史進(jìn)行二進(jìn)制搜索發(fā)現故障。
尋找答案
49. 谷歌搜索。
50. 論壇帖子。
52. 搜索堆棧交流。
53. 創(chuàng )建堆棧問(wèn)題。
其他
54. 聘請專(zhuān)家?？赡茉诙虝r(shí)間內成本很高。
55. 招實(shí)習生。聘請專(zhuān)家的相反方法就是聘請新手。有時(shí)候初學(xué)者飽滿(mǎn)的熱情能讓他們從不同的角度來(lái)解決問(wèn)題。
56. 改變要求。如果你不能修復缺陷，那么可以改變要求。通過(guò)解釋各種成本需要，也許能讓客戶(hù)改變他們的初衷。
57. 更改上/下游系統。
58. 循序漸進(jìn)地學(xué)習技術(shù)。
59. 通過(guò)斷點(diǎn)檢查配置。更改關(guān)鍵配置值，并確保已經(jīng)斷點(diǎn)，這樣能夠讓我們無(wú)所顧忌地設置配置。
60. 系統化。有時(shí)候我們需要將三四件事情組合在一起，那么可以將已經(jīng)試過(guò)的組合記錄下來(lái)，如果需要的話(huà)一定要嘗試各種的組合。
英文原文：60 Problem Solving Strategies
聯(lián)系客服
