問題常出在使用方式而非第三方本身#

很多問題是因為你的程式碼使用第三方 library 或應用的方式不對，而非第三方軟體本身有 bug。因為第三方軟體以黑箱形式整合，協調的機會較少。

瀏覽第三方原始碼#

當你需要了解某個 API 為何行為異常，或某個加密的錯誤訊息從何而來，最有力的方法就是閱讀第三方的原始碼。

具體做法：

• 定位你感興趣的函數或方法定義，從那裡跟著程式碼走
• 你不是在找 library 的 bug，而是要更深入理解它如何運作以及如何與你的程式碼互動
• 理解錯誤訊息：搜尋錯誤訊息的文字，找到產生它的程式碼
• 使用 ctags 或 etags 建立索引，或用 IDE 的程式碼導航功能快速定位

ctags -R .

對於開源程式碼，也可以透過線上搜尋服務（如 Black Duck Open Hub Code Search）來瀏覽。

用 debug build 連結第三方#

更強大的技巧是將第三方程式碼以含 debug 資訊的方式建置，然後連結 debug 版本的 library。這讓你可以用 symbolic debugger 逐步執行第三方程式碼，檢視變數，就像除錯自己的程式碼一樣。

有些廠商（如 Microsoft）會隨程式碼一起發佈 debug builds 或 symbols，省去你自行建置的麻煩。

修正第三方程式碼（最後手段）#

如果確認 bug 在第三方程式碼中，且你有原始碼存取權限，可以考慮直接修正。但這應該是極端情況下的最後手段：

• 確認沒有合理的 workaround
• 確認廠商無法幫你修復
• 了解你將需要在第三方每次更新時維護這個修改
• 確認你在法律上有權修改（注意 license）
• 對於開源軟體，向上游提交 pull request 是正確的做法

確保手邊有第三方原始碼#

• 開源軟體：直接下載
• 開源 OS 發行版：以套件形式下載（例如 sudo apt-get install glibc-source）
• 開發平台：通常會安裝重要的原始碼（例如 Visual Studio 的 VC\crt\src、JDK 的 src.zip）
• 專有軟體：如果價格不太離譜，在訂購時堅持取得原始碼——這是合理的保險

重點回顧#

• 取得你所依賴的第三方程式碼的原始碼
• 透過閱讀原始碼來探索第三方 API 問題和加密的錯誤訊息
• 連結 library 的 debug build
• 只在沒有其他合理替代方案時才修正第三方程式碼