第2條：在網上確切地查詢你所遇到的問題，以尋求解決問題的靈感

現在很少有哪個工作場所不能上網，如果在一個無法上網的地方開發程序，那我的效率會很低。遇到代碼錯誤的時候，我們應該上網搜索，或者與同事一起尋找解決辦法。

有一個相當有效的搜索技巧，是把由第三方組件所給出的錯誤消息打上雙引號，并將其粘貼到瀏覽器的搜索框里面。把待搜索的內容放在一對雙引號中，意思是要告訴搜索引擎：只搜索與該內容精確匹配的頁面。這樣做可以使搜索結果更加準確。還有一個很有用的技巧，是把與錯誤有關的程序庫或中間件的名稱、對應的類名或方法名，以及所返回的錯誤代碼，也一并放在搜索框里面。要查找的函數名稱越罕見，搜索到的結果也就越確切，例如，搜尋PlgBlt所得到的結果，要比搜尋BitBlt好得多。此外，我們也應該試著搜索意思相近的詞，例如，除了搜索“hangs”（掛起），還可以搜索“freezes”（凍結），除了搜索“disabled”（禁用），還可以搜索“grayed”（變灰）。

要想解決一些與API調用有關的難題，我們通常可以觀察其他人是如何使用這些API的。我們可以看看開源軟件如何使用某個函數，如何對傳給該函數的參數進行初始化，以及如何解讀函數所傳回的結果。在這種情況下，專門用來搜索代碼的引擎（如Black Duck Open Hub Code Search），要比Google那樣的通用引擎更好。例如，如果在這個搜索引擎里面查找mktime，并且只看與某個項目有關的代碼，而過濾掉程序庫的聲明及定義，那我們就會發現下面這樣的代碼片段：

通過上述代碼片段，我們可以看出：mktime函數與localtime函數有所不同，它要求傳入的年份必須是完整的數值，而不是距離1900年的偏移量，而且它的月份是從1開始計算的。這兩個地方經常會出錯，對于那些沒有仔細閱讀函數文檔的人來說，更是容易在調用時傳入錯誤的參數。

在查看由搜索引擎所給出的結果時，我們要注意這些結果是從哪個網站抓取到的。StackExchange旗下的網站（如Stack Overflow）通過很多措施來鼓勵用戶進行有效的交流，因此，在由搜索引擎所給出的結果中，有很多比較切題的討論及答案都來自這個系列的網站。在瀏覽Stack Overflow上面的答案時，不僅要看提問者所接受的那個回答，而且還要看看其他那些贊同數量比較高的回答。除了答案的正文，我們還可以關注答案下面的評論，因為很多人都會通過評論的方式來給出新的消息，例如，有人會在評論中告訴大家，自己發現了一個可以避免錯誤的新辦法。

如果你把自己精心構造的關鍵詞放入搜索引擎之后，并沒有得到有用的結果，那么或許意味著你找錯了目標。對于常見的程序庫與軟件來說，你不太可能成為第一個遭遇某問題的人，因此，如果在網上找不到類似的描述，那可能說明你對問題的判斷發生了偏差。例如，你本來以為程序崩潰的原因是某個API函數的實現有bug，但實際上卻是傳入的日期有誤。

如果網上找不到答案，那你可以在Stack Overflow網站提問，把自己所面對的問題描述出來，然而，這需要花一定的時間來構建一個簡單、自足且正確的范例（SSCCE）。凡是在論壇發問，都應該遵循該SSCCE原則，也就是要給出一個其他人可以直接復制、粘貼并編譯的例子，使得他們能夠看到你所經歷的問題（參見第10條）。對于某些編程語言來說，甚至可以把范例代碼嵌入SourceLair或JSFiddle這樣的在線IDE，令大家能夠在網上直接看到運行效果。sscce.org網站詳細解釋了應該怎樣針對具體的語言和技術來構造良好的范例。Eric Raymond所寫的文章《How To Ask Questions The Smart Way》也與這個話題有關，值得一讀。

筆者發現：只要我能夠恰當地描述問題，并且附上合適的范例，那么該問題的解決方案通常就會自然地浮現出來。就算我自己找不到答案，這樣的問題也可以吸引一些懂行的人過來進行試驗，他們或許能找到辦法。

如果你所遇到的問題在某種程度上與開源的軟件庫或程序有關，而且你認為它們的代碼中很可能有bug，那么可以聯系其開發者。常見的做法應該是訪問那個開源項目的bug追蹤系統，并在上面提交一項事務。提交的時候，也應該首先確保其他人沒有報告過類似的bug，并且要把重現該問題的詳細步驟準確地寫進去。如果那款軟件沒有bug追蹤系統，那你可以給它的作者發郵件，郵件要寫得相當謹慎，措辭要得體、語氣要謙和，因為大部分開源軟件的開發者都不是你的雇工。

要點

■ 把錯誤消息打上雙引號，以便在網上準確地進行搜索。

■ 認真查看StackExchange系列網站上面的回答。

■ 如果上述兩種辦法都不見效，那你可以自己提問或提交事務。