我們有一個會員資料審核的功能，原本規劃的是，尚未成為正式會員之前是無法登入網站的；後來設計師想改成仍可登入網站，但在個人資料那邊顯示「審核中」，並且可以隨時「編輯資料」，至於接下來會發生什麼事情，就不管了⋯😱
這就衍生出一個問題了，理論上，每變更一次就要發送一次審核提交，即同一個申請單但會有不同版本；為了避免極端狀況（例如在一個短時間內準會員修修改改、提交多次，我知道可能機率不大，但仍可能發生），我建議在審核期間鎖住編輯資料的功能，除非被駁回重審才可以解鎖、減少審核負擔。
但後來 RD 決定不鎖。
於是，對於在後台負責審核的人，如果點開的審核單不是最新版本，我建議單子的審核按鈕也是鎖著，並在下方顯示「已有最新版本」的提示文字。
但後來 RD 也決定不鎖，採取送出後再檢查是否為最新版的審核單？不是的話就跳出警示框。總之就是先檢查與後檢查的差別，但最後都殊途同歸。
結論：
相對於核心功能來說，用最少的資源去處理極少的極端情況來說我是可以接受的；但我也發現人們在思考一件事情時無法更系統性的考量接下來會牽涉的範圍有多少？站在單一視角來看會誤以為對用戶友善，但限制條件或蝴蝶效應加進去之後，就會看清整體的邏輯與脈絡衍生出的影響是什麼，所謂一髮動全身。
這就像每當客戶拋出需求時，我們都會再三思考這有無用戶或商業價值？是否符合產品目標？對現有的架構與功能的影響是什麼？設計開發成本有多少？是否有法律的問題等等。
沒有最好的方案，只有最適合的方案。
