整理編輯頁時，很容易看到相似的程式：讀取資料、檢查欄位、寫入地址，再回傳結果。AI可以協助找出重複，也能提出抽成共用方法的建議。

但決定合併之前，還要問一件事：其中一個功能的規則改變時，另一個是否也應該跟著改？今天想聊聊的是責任邊界與耦合。共用程式會讓功能產生連動，我們需要判斷這個連動是否合理。

看起來相似的更新流程，要不要共用？

假設客戶資料裡保存了一組常用收件資訊，包含姓名、電話與地址。建立出貨單時，系統會把這些資訊複製到出貨單，作為這次配送的收件資料。之後修改常用資料，不會自動改動已建立的出貨單。

因此，系統有兩個編輯功能：一個修改客戶的常用收件資訊，另一個修改某張待出貨單的收件資訊。兩邊的程式都會檢查必填欄位、驗證電話格式，再把姓名、電話與地址存回去。看到這些相似的步驟，很容易想把它們合併成一個共用方法。

但兩個功能允許修改的條件不同。客戶可以更新常用地址，供之後建立出貨單使用；某張出貨單的地址能不能修改，則要確認它是否已經交付物流。修改這次配送的地址，也不代表要更新客戶的常用地址。

所以，電話格式等一致的檢查可以考慮共用，但「能不能修改」與「修改哪一份資料」，仍要依各自的操作決定。判斷是否合併，要看這些步驟是否遵守同一份規則。

用一個合理的變更，檢查邊界

那麼出貨單修改地址時，要確認新地址是否在目前配送方式的服務範圍內。這條規則應該套用到所有儲存客戶常用地址的地方嗎？

不一定。可能允許保存尚未使用的地址，等建立出貨單時再檢查能否配送。這取決於已確認的業務規則，不能因為兩個功能呼叫同一個方法，就順便一起限制。

如果每次新增規則，都要往共用方法傳入「來自哪個畫面」「是否略過出貨檢查」之類的參數，就值得回頭看：這個方法是不是承擔了不同操作的責任？有條件分支不一定錯，但每個呼叫端都需要一套例外時，共用可能已經沒有讓規則更清楚。

共用可以只到真正一致的部分

兩個功能不共用整段流程，不代表所有程式都要各寫一份。如果電話格式、地址欄位的基本檢查確實遵循同一份定義，就可以共用這些檢查；是否允許修改、是否符合配送條件，則留在各自的操作裡。

畫面元件也是同樣道理。兩頁可以共用收件資訊的輸入元件，但由各自的頁面決定哪些欄位可編輯，以及呼叫哪個儲存操作。共用顯示與輸入，不必連業務流程一起綁住。

另一方面，若客服單筆修改與批次修改都在處理同一種出貨單地址變更，就應確認兩者都遵守相同的修改限制。這裡若各自複製規則，以後調整時就可能改A漏B。真正需要一致的規則，仍然值得集中維護。

所以取捨不只是重複幾行程式。分開會增加重複維護的成本，合併則會增加連動的範圍。應該承受相同規則變更的功能，才適合共用那份規則。

決定是否共用，要看規則是否應該一起改變。理解責任邊界，才能判斷AI提出的合併是在集中同一份規則，還是把不同流程綁在一起。

「這兩段差不多，我把它們合併了。」
「那邊有一個規則不一樣。」
「沒關係，加個參數判斷。」
「這邊也有一個例外。」
「再加一個。」
「所以現在呼叫要傳什麼？」
「true, false, true。」
「什麼意思？」
「等一下，我看一下原始碼。」