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