在現在這種講求快速開發的開發模式，我們通常不太會自己將所有功能都自己硬刻出來，而是會去使用第三方的套件來跟自己的系統做串接，這時候就會需要去閱讀他的說明文件，或是去讀他的原碼，來推敲出這個套件是如何使用的

理想總是美好的，看完他的說明文件，覺得這個套件怎麼那麼適合，但真的要使用時，常常會與到以下情況

常見狀況

• 在套件中有提供說明文件，但他的說明僅出現關鍵指令，在環境設定的部分用文字敘述，而沒有範例程式碼可以參考
• 在套件中看到範例程式碼，依照他的指示複製到自己的專案中，卻無法成功運行

可以嘗試的方向

上面這兩種問題是我在使用一個新的套件時最常發生的問題了，以下提供幾個我時常會使用的方法來當作參考

將程式中的錯誤訊息拿去google

當錯誤發生時，如果很幸運的有錯誤訊息發生，就將錯誤訊息放到google上吧，就算沒解答也可以找到出問題的方向

檢查原始程式碼中是否有測試用的專案

如果說說明文件是放在他的原始檔下的readme.md中，可以到它的原始檔中找找有沒有作者自己拿來測試的範例程式碼，通常會放在example或是test中，如果有可以將它clone下來到你的環境中運行，成功後可以嘗試複製他的程式碼到你自己的程式中，一步一步的嘗試

將說明文件的關鍵指令放到github中搜尋，看其他人怎麼使用的

在github中，除了可以看到他人的程式碼之外，也可以透過搜尋欄來找尋是否有人跟你用了一樣的程式碼

除了可以將關鍵套件放到搜尋欄中，還可以選擇你需要的語言，類型，時間排序來找尋其他人的作品

在觀摩這類的作品，盡量從星星少的開始看起(0~10顆星)，因為星星越多，就越有可能是大神寫的作品，它裡面就有可能不是單純使用這個套件，而是混和其他的功能一起使用，參考這類的大部分時間只會越看越不懂，反而是星星數較少的，都是剛剛開始摸索的作品，可能寫法不是那麼漂亮，但就邏輯性或是寫作方式一定跟剛開始使用的我們進一些，看懂的機率就大大提升了

將問題整理好，放到社群中詢問

如果說一個問題你卡住很久了，那就可以考慮找人詢問看看了，以下提供幾個提問的技巧，除了可以讓別人可以提高回答你的意願，也可以讓幫你debug的人更容易了解你的問題

1. 透過線上的IED來把你的問題重現，而且盡量環境越單純越好
2. 如果環境不好重現，則將你能提供的資料提供的越詳盡越好，因為有可能再整理文件的時候，就找到錯誤的原因了(這個還蠻常發生的)
3. 建議詢問一個問題，大概卡關1~3天再做詢問，否則太常發問，會有點像是放羊的小孩一樣，到最後沒有人想要幫你的
4. 最最最重要的一點，提問後，對於每個回答的人，要表達感謝，因為他們是無償的幫你debug，有可能你遇到的這個問題是他花了1星期解出來的，願意經驗分享就十分的難得的了