上下文切換與除錯
接手專案時，如何提昇除錯的效率
我在 Gaiwan 工作，有時候會需要接手同事的專案。最近我的工作是：「接手同事的專案，並且設法修復專案裡的一個臭蟲 (bug)。」
當我跟客戶談話時，客戶告訴我的資訊如下：
從網站上的購物連結點下去之後，本來預期使用者將可以順利完成購物，即使用者會取得授權於是可以開始觀看線上影片。然而，此事沒有發生，我們猜測，可能是 webhook handler 沒有正常地運作。
談話的那時，我剛接手專案，整個專案到底怎麼運作的，我一無所知，所以我只請客戶提供了一組標準資訊：「如何重製這個 bug ？」
運作模型
接手新專案最困難的事是「上下文切換」。剛接手專案時，整個專案的上下文在我的腦海一面空白。這種空白導致的效果會讓我想一步做一步，因而工作效率低落。
一開始，我先閱讀專案的說明文件，並且照著文件裡的指示，將專案啟動了起來。很快地，我就遇到了第一個問題：「本機端的專案啟動之後，網頁是沒有畫面的，因為前端丟擲了一個例外錯誤。」思考了一下之後，有鑑於 staging 環境與 production 環境都沒有錯誤，這個錯誤只發生在本機端，我決定採用繞道的方式，循著丟擲例外的程式碼週遭看了一下，把某段程式碼整塊註解掉之後，本機端至少有畫面可以顯示了，於是，思緒接著開始思考下一步。
第二步是去看客戶提示的 webhook handler 。找到之後，第一時間也不是看得很懂。搭配了文件之後，腦中最初產生的運作模型如下：
step 1:
使用者在 shopping cart 點選購物連結 ---> [shopping cart 觸發 webhook ]
step 2:
[shopping cart 的 webhook] ---> 送出 http post 到 [Gaiwan Video Library webhook handler]
註：
shopping cart 是 Wordpress 系統
Gaiwan 公司幫客戶開發的程式是 Gaiwan Video Library。
思考錯誤假設
照理來講，如果有想清楚運作模型，此時可以做的 bug 假設應該是：
webhook 沒有觸發。
webhook handler 沒有正常地運作。
而實際上，我工作時，並不是一次想清楚上述兩個假設，而是先想一個假設，並且驗証完一個假設之後，再想下一個可能出錯的假設是什麼。此外，也是在我反覆地修改本機端的程式，觀看程式的變化之後，運作模型才漸漸地進入我的腦海…。
思考驗証機制
在詢問同事與客戶一些問題之後，加上做了一些實驗、反覆地讀了文件。我把兩個關鍵的驗証想清楚了：
如何驗証 webhook 有沒有觸發？
如何驗証 webhook handler 有沒有正常運作？
webhook 有沒有觸發的驗証頗繞彎，最合理的作法是我要登入客戶的 wordpress 系統，去查看 wordpress 裡的 logs 。這部分滿繞彎的，因為我長久以來一直對 wordpress 不熟悉。但是，換個角度來看的話，我要處理的除錯問題是兩個系統之間的整合運作，所以本來就應該要把 wordpress 生成的 logs 納入考慮。
閱讀 webhook handler 的源碼之後，我大概了解了 webhook handler 的邏輯。它依序做了以下的事：
安全性驗証機制，比對 http request body 產生的驗証碼，確認觸發真的來自於 webhook
從 HTTP POST 的 body 裡，取出兩個重要的資訊： user 和 sku 。並且送給與資料庫互動的商務邏輯層。
商務邏輯層會先看 user 和 sku 是否存在於資料庫，並做對應的處理。 user 如果不存在，就建立新 user 。sku 如果不存在，就不做任何處理。
我做了以下的驗証：
驗証是否通過安全性驗証。我隨手自己生成了 HTTP POST 去觸發 webhook handler 試看看。
我去到 wordpress 系統裡，看看之前失敗的購物車操作，是送出怎樣的 sku ？
我去到 Gaiwan Video Library 的資料庫，看看資料庫裡有哪些 sku 存在？
最後，就成功地定位了 bug 的所在位置。
總結
花費了比預期更久的時間才定位錯誤一事，檢討了之後，我認為應該考慮把『運作模型』、『可能的錯誤假設』、『驗証機制』三件事都畫進一張圖。就叫它運作模型圖吧？並且多畫這種圖。
首先是下次如果處理類似的問題，我可以邊畫圖邊前進，除錯會更有系統。另外，如果要交接這個專案給下一個人，有先把運作模型圖畫出來的話，下一個人也可能會輕鬆許多。