Re: [請益] 工作四年多開始迷惘消失
權限部份就像 BignoZe 說的, 權限一個 table 處理就解決了,
那開例外就會變成下一個 query 命令就好不用動程式,
參考
https://goo.gl/eKaPah
截錄
having a table of possible permissions,
a table of users, and a link table between them
is the best and clearest way to organize this
後面的部份沒有詳細描述, 因此也沒有辦法對它詳細做回應,
粗略估計可以建一個 ExceptionEventTable
把每次補償方案也視為一種權限,
程式裡就跟處理權限一樣去做就好,
有需要未來修改時列入考慮的事項看加在程式註解或 DB 欄位記錄都可,
解約離開的人刪帳時一併刪這 table 的記錄
大概4醬, 感覺跟 code 關係沒很大 @@
※ 引述《accessdenied (存取違規)》之銘言：
: 還是很多人對 clean code 的烏托邦有著不切實際的夢想....
: 醒醒看看 real world 的例子吧......
: 下面都是真人真事
: 有一天，客服接到客訴，客人發現我們用戶條款有模糊不清的地方，導致客人使用我們的
: 服務權益受損。因為某個功能，原本設定為VIP方案才能使用，但用戶權益沒有釐清，導
: 致這個初階用戶認為自己應該也享有這個功能。
: 在解說無效下（通常都是無效的），客戶要求退費並且威脅要 消保官和發文抹黑，客服
: 經理當然為了公司品牌、保全用戶，決定個案處理讓這位客戶能特別使用這個VIP功能...
: .，並且承諾明天就生效。
: 回到 RD 場景，這種 Member.Level 1 的客人要能夠使用 某特定 Level 3 的功能，而且
: 不是所有 Level 3 都能用，只有某一隻 Level 3 的功能....
: 幹，明天就要生效？RD 默默地下 SQL 查出這位客戶的 ID, 在那隻 Level 3的功能的 au
: thorize code 寫下一行非常骯髒的
: if (cid == 65432) return true;
: 上版。
: 事情過後，客戶不吵了，RD 內部安排要不要 重購 這個 hotfix, 在 Db 內設定一個exce
: ptional member 的資料表，讓客服可以有 UI 設定這種 Level 不到位的特殊顧客？
: 客服經理說：不用，這種情況不會再發生！我們已經更新的客戶權益說明，排除這種誤解
: ！不會再有下一人！
: RD 面面相覷，客服經理說不會再發生，那我們還需要投入資源做一個例外模組嗎？還是
: 就讓那個帶著 magic number 的怪異 if 停留在程式碼中？
: 真實世界的選項是什麼，相信大家猜得到。
: 過幾天，又發生公司因為系統上版過久，超過官網公告的 downtime 維護時間。等著使用
: 公司系統的用戶逐一抗議自己的權益受損，支付吃到飽的費用卻超過公告時間無法使用..
: ..
: 接下來談的補償辦法，又是目前系統根本沒有設計過的方式，跟上面提到超越Level限制
: 又是不同的作法。RD 們又開始那著這些客戶清單，一條條地輸入
: If (cid == .....
: 回頭來看，當初沒有開發那個 Level 例外的模組是對的，因為後面發生的例外處理，解
: 決方案是什麼根本無法預料！
: 但是，這就是「營運」啊！這些處理真的就讓公司能在市場上繼續發光發熱！
: 就連 MS 也做過類似的事情，這未來有空再說。
: 這些dirty code有沒有影響未來系統的修改？
: 有的！像是這些寫死的邏輯，那些客戶現在還在使用嗎？還是早就解約離開了？還在使用
: 的，我們更新功能要怎麼維持當初客服保證的補償不會受影響？
: 這些都變成修改系統的干擾。
: 但是，這些頂多增加修改的成本和難度，卻沒有害當初公司業務根本做不起來。
: 這就是一種技術債槓桿。
: 我想問那些把 clean code 和 DP 看得甚高的工程師們，在這樣現實的商業生活中，你會
: 怎麼做的讓我刮目相看呢？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.80.109
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1523802502.A.835.html
→
04/15 22:59, , 1F
04/15 22:59, 1F
討論串 (同標題文章)