WordPress 最方便的地方是能擴充，最容易失控的地方也是能擴充。當一個需求出現，我們很自然會想再加一個外掛、再掛一層判斷，先讓功能動起來。但如果舊邏輯仍在背後替同一件事做決定，新功能就不是接手，而是疊上去。
看起來保守，其實更難控制
我曾經也直覺想在原本流程外面多包一層：舊的先留著，新的只負責修正結果。這樣好像什麼都沒有真正移動，風險比較小。但只要原本的流程本身就是負擔，多包一層並不會讓它消失，只會讓系統先付出一次代價，再付出第二次。
更麻煩的是，日後結果不對時，沒有人能一眼看出到底是哪一層做了最後決定。短期少動一點，長期卻多出兩套需要理解的世界。
一個功能最可靠的狀態，不是有很多層保護，而是每一層都知道自己只負責哪一件事。
客製外掛應該是一條乾淨的邊界
後來的方向變得很單純：既然新的客製外掛要負責，就讓它完整接手那一段流程；既有外掛保留原樣，不在第三方程式裡偷偷修改，也不讓兩套邏輯長期纏在一起。
這樣做不只是為了快。它讓維護者能清楚回答：哪個外掛負責資料、哪個只負責顯示、出了問題要停哪一段。可關閉、可替換，也才真的可回復。
整合前，先問誰擁有最後答案
遇到 WordPress、WooCommerce 或 ERP／CRM 串接需求時，我現在會先問：這筆資料最後應該聽誰的？同一個狀態有幾個地方會改？失敗後由誰重試？
這些問題看起來不像寫程式，卻會決定程式日後是工具還是負擔。整合真正要接起來的，從來不只是一個 API，而是一條能被人理解的責任鏈。