在忙完了 WordCamp 之後，我調整了自己的工作節奏，從原先做二休一，改成做五休二，把之前累積的工作放在早上集中力最高的三小時來處理，然後上午做完後就下班了，下午看是要繼續弄產品，還是去跑個步動一下。
這樣的節奏在第一週運作的很順利，看到專案每天都有進展對客戶也有所交代，但到了第二週開始有些狀況，下午的時間常收到客戶的緊急回報，因為這些問題會影響到客戶當晚的作業流程，因此我會放棄下午的行程優排除客戶的問題。
檢查後才發現是第一週開發的功能所影響的，這些新功能開發完成時雖然我都有進行測試，並且確認可以正常運作後才交付，但這週遇到的問題是我完全沒想到的情境，我沒有預料到做了 A 功能竟然會造成 B 功能的錯誤，於是只能當客戶在實際使用時才發現問題。
這樣的狀況持續了幾天，結果變成一整天都在處理專案，上午開發下午除錯，就讓我反省為什麼會有這些臭蟲的發生？難道這些蟲是無法避免的嗎？就算無法避免有沒有更好的通知機制能讓我第一時間就知道？
因此我想藉由這篇文章來分析一下這週遇到的問題，並且提出可能的解決之道。情境是這樣：
因為 wp_postmeta 資料表已經儲存百萬筆的資料，在載入文章編輯頁的時候速度變得很慢，原先的欄位是用 ACF Repeater 開的，這些資料每天都會有數百筆的增長，因此我跟客戶提議把這些資料拉出來，新開一個自訂資料表來存放以及查詢，並且用 WP_List_Table 來彙整所有資料，不用點進各別文章查看。
我將本週遇到的問題類型分為以下三種：
ㄧ、原本應該發生的行為沒有觸發
重構前有一個功能是可以在前台寫入這個資料，然後在寫入後會觸發第三方的 API 做事情，結果重構後觸發 API 的行為沒有發生。觀察我自己的重構方式是在加入新的寫入方式後，把原先舊有的程式碼全部註解掉，結果我以為註解掉的部分就只有寫入資料的功能，想不到觸發 API 的程式碼也被我一併刪了。
舊版寫入資料的方法有將近四十行程式碼，觸發第三方 API 僅有六行，因此一整遍看過去會以為這四十六行就是只有處理寫入資料，而忽略了觸發 API 也在裡面。想到幾個可以改善的地方是：
- 把寫入資料的程式碼包裝成方法或函式，這樣在視覺上就會是一個獨立的事件而非一連串的行為
- 增加明顯的程式碼註解，帶有開頭跟結尾，並且把空行的間距加大，讓自己可以很明顯的看出處理同一功能的區塊開頭與結尾
- 增加返回的型別提示，確實定義每個任務執行完後要回傳的是什麼資料型態，以這個例子來說，寫完資料觸發 API，要回傳的應該是 WP_HTTP_Response 物件，如果我有指定的話，在測試重構後的方法我就可以即時知道回傳東西有誤，進而發現到我漏了觸發 API 的行為
事實上我有時候都會懶得把一連串的程式封裝成方法或函式，因為每多一個函式就要多寫程式碼，像是函式的命名、帶入參數的定義、返回資料類型、註解說明，尤其是要找問題的時候必須在多個函式之間切換很麻煩，但為了程式碼的維護性，還是要逼自己養成這個習慣才行。
還好在我改用 PhpStorm 之後裡面有一個很貼心的重構功能，可以把選取的程式碼直接變成函式：
點下之後就會在同一個檔案的最下方加入新的方法，他還會自動所需要的參數帶入，並且寫好參數的註解，算是省下不少手動輸入的時間，另外在查看函式的部分，只要把游標停留在函式上，按住 cmd + 滑鼠點擊，就會自動跳到定義該函式的區塊或檔案以方便查看。
有了這兩個實用的功能應該不能再用麻煩當藉口了，乖乖的把程式碼封裝起來吧！
二、重構不完整
新功能有一個方法是檢查特定的 user id 是否有在新建立的資料表中，藉此取代原本判斷 user id 是否存在於 Post Repeater 欄位中的邏輯，這部分我已經有獨立一個方法來做判斷，因此我是直接替換這個方法裡面的判斷邏輯。
結果想不到除了這個方法以外，還有一支散落於某處的函式也是在處理一樣的功能，結果我只改了方法沒改到函式因此發生問題，這讓我學到在重構方法前，記得先用全站搜尋功能來尋找原始的 user id 判斷邏輯有寫在哪寫地方，然後列出所有的方法與函式。
更好的做法是要將這些重複的地方整合為一個方法，就能避免改了 A 忘了 B，趁著這次除錯就可以順手把這件事做起來，如果時間趕可以先寫個註記，萬一之後又要調整就不會漏了它。
三、預期外的 save_post 勾點
新增資料的部分我是用 ACF 設定頁來處理，這樣就可以省下開一堆欄位的時間，然後當儲存後抓欄位值寫入資料，一般儲存文章的勾點是 save_post，而 ACF 的是 acf/save_post，問題出在我為了要判斷當下儲存的頁面是 ACF 設定頁，因此用了 get_current_screen() 來取得目前所在頁面，當頁面 ID 等於我的設定頁 ID 時才會執行資料寫入。
因為這個勾點的名稱我預期是只有在儲存 ACF 設定頁面才會觸發，為了精簡程式碼我把 get_current_srceen() 的判斷拔掉了，想說應該不需要這層判斷，但沒想到一般文章在儲存時也會觸發到，這導致寫入資料表時少了必要欄位而噴錯，造成客戶沒有辦法在後台更新文章。
於是還是乖乖的把判斷加回去，但第二個問題來了，因為我有用另外一個 ACF 設定頁以表單的方式放在前台供客戶使用，在前台因為沒有 get_current_srceen() 這個方法，因此設定頁 ID 的判斷會出錯，要先用 function_exists() 來判斷函式是否存在，才能繼續做設定頁 ID 的判斷。
第一個問題我想到的解決辦法就是用任何勾點前先去爬一下原始碼，看他們會在哪裡被觸發，使用 PhpStorm 並且有設定 WordPress 為專案環境的話，在每個勾點前面都可以看到一個小 h 的圖示，點擊後就會直接前往勾點定義的來源：
第二個問題的解法是在使用 WordPress 內建的函式時，要先意識到該函式是否有前後台的區別，如果懶得想最快的解法就是用之前一律做 function_exists 判斷就不會錯了，然後當回傳 false 時直接返回終止程式執行。
–
回想我的除錯過程都是客戶貼重大錯誤的截圖給我，然後我再進主機或是網站後台去查看錯誤日誌，然後從裡面尋找程式出錯的地方，我就在想不知道有沒有更快速的方法可以得知問題在哪，爬了一下找到這個解：https://www.businessbloomer.com/woocommerce-email-fatal-error/
add_action( 'woocommerce_shutdown_error', 'bbloomer_email_fatal_errors' );
function bbloomer_email_fatal_errors( $error ) {
$email_subject = '網站發生重大錯誤！';
$email_content = sprintf( __( '%1$s in %2$s on line %3$s', 'woocommerce' ), $error['message'], $error['file'], $error['line'] );
wp_mail( 'm615926@gmail.com', $email_subject, $email_content );
}研究後才知道原來 PHP 有 register_shutdown_function 函式，而 WooCommerce 就是利用這個函式來來做錯誤日誌的紀錄，並且在裡面放 woocommerce_shutdown_error 的勾點，就能實現當 500 Error 時收到通知，而不用從伺服器底層處理。
我期許自己在除錯的時候不是只要把眼前的問題解決就好，而是有餘裕去反思為何這個問題會發生，並且在除完錯的當下重構程式碼來避免再次出現，甚至可以改進工作流程來減少緊急狀況的發生，為了努力實現只上半天班，一定要將重大錯誤發生的頻率降低才行啊～
