一段修改狀態的程式，誰能改？什麼狀態能改？哪些入口可能繞過檢查直接改？

除了確認條件寫得對不對，也要看這段判斷放在哪裡，以及其他功能會不會經過它。這是從一段程式往整個流程看，判斷設計是否有遺漏的觀念。

即使有AI協助產生程式，我們仍需要這份理解，才能看懂它提交的修改，知道哪些地方值得繼續追查。今天用訂單出貨與退貨的情境，從四個需要確認的問題聊聊。

狀態這樣改，符合實際流程嗎？

假設公司的規則是：商品交付物流前可以取消，交付後不能取消，但符合條件時可以申請退貨。以一張整批出貨的出貨單來看，可以記錄待出貨、已出貨與已取消；退貨另外建立單據，追蹤申請、收貨與驗收進度。

取消代表停止原本的出貨。商品送出後再申請退貨，則要保留出貨紀錄，繼續追蹤商品是否退回。如果直接把出貨單改成已取消，後續程式就可能把「曾經出貨、正在退回」當成「沒有出貨」。即使另有異動紀錄，出貨單目前的狀態仍然表達錯了。

因此，「已出貨，而且正在退貨」可以同時成立；申請退貨也不代表倉庫已經收到商品。先理解這些差別，才能判斷程式裡的修改是否合理。

用Enum列出幾種狀態，能讓選項清楚，但不會自動阻止已出貨改成已取消。Review時仍要找到執行取消的程式，確認它會檢查目前狀態，而不只是接受一個新的狀態值。

畫面擋住了，後端還要檢查嗎？

已出貨時，停用取消按鈕並說明原因，可以讓使用者知道目前不能操作，不必按下去才收到錯誤。

但後端不能把畫面檢查當成保證。使用者開啟畫面時可能還是待出貨，等到按下取消，倉庫已經完成交付。其他程式也可能直接呼叫同一支API，根本沒有經過這個畫面。

後端收到取消要求時，必須依目前資料確認能不能執行；若不能，就拒絕修改並回傳原因，讓畫面更新資訊。

前後端看起來都有判斷，卻各有用途：畫面幫助使用者操作，後端確保不能取消的單據不會被取消。看到重複條件時，要先理解用途，不能直接把其中一邊刪掉。

如果看到一段共用的狀態更新？

通常就要往兩個方向看：誰有用到，又有誰沒用到。改Code最怕「改A壞B」，也怕「改A漏B」；共用程式改動的行數可能很少，影響卻不一定只在眼前這個功能。

先看有用到的地方。假設客服後台與批次取消都呼叫同一段程式，這次為了讓畫面顯示原因，調整了取消失敗的回傳方式，就要確認批次程式是否也能正確處理。如果原本回傳失敗結果，現在改成丟出例外，批次是否會因為其中一張不能取消，就中斷後面所有單據？客服畫面正常，不代表其他使用者也不受影響。

再看沒用到的地方。搜尋共用方法的呼叫位置，只能找到已經使用它的程式。如果還有舊批次直接更新出貨狀態，就不會出現在這份清單裡。因此也要搜尋狀態欄位與資料表的更新位置，確認是否有相同操作走了另一套處理。只改共用方法，這些地方可能仍然沿用舊規則。

找到不同寫法後，也別急著全部改成共用。先確認它們是不是同一種操作：取消出貨與申請退貨都會改狀態，但條件與後續處理不同。真正需要一致的是相同的業務規則，不能只因為都在更新狀態，就硬塞進同一個方法。

所以修改前，要先弄清楚哪些功能會跟著改變、哪些地方需要另外補上。測試也要包含其他呼叫端原本正常的操作，才有機會發現這次修好A，卻讓B出問題。

併發衝突：取消與出貨同時發生呢？

那如果同一張出貨單，可能同時被不同程式處理，這就需要考慮併發造成的狀態更新衝突。

例如，取消與確認出貨幾乎同時執行，兩邊都先讀到「待出貨」，也都通過檢查。如果後續直接更新狀態，就可能一邊寫入已取消，另一邊寫入已出貨，最後還各自回報成功。資料庫只留下後一次寫入的狀態，客服卻可能已經看到取消成功，出貨流程也繼續往下走。

這類問題的結果會受到執行先後影響。它不需要很大的流量才會發生，只要兩個操作剛好重疊就有機會遇到。各自有檢查，甚至使用同一段共用程式，都不代表兩次執行不會互相衝突。

併發問題容易藏在單次流程之外。除了確認這次操作的條件正確，也要想到：
檢查通過後、資料寫入前，會不會有另一個操作先改掉它？

遇到狀態更新，要了解誰能改、規則在哪些地方檢查、改動會影響的範圍，以及同時修改時會不會互相衝突。

兩位室友出門前，各自打開冰箱看了一眼，都發現牛奶喝完了，於是各買一瓶回家。
「我出門前看冰箱沒有牛奶啊。」
「我也是。」