開發日記 — 會員功能架構、後端實作
2023 嶄新的一年，回顧一下 2022，針對我做過一系列會員相關的功能，並重新思考一次今年學到的知識與系統設計的想法，感謝主管與同事的建議與幫忙讓這一系列的專案能順利完成，達成人生新的里程碑。
以下影片是 demo 畫面，主要會員功能集中於會員等級、歸戶折價券、會員權益這三個功能，筆者是負責後端部分的系統設計與開發。
會員歸戶折價券
前情提要，此情境系統中存在一個會員中心與各個站台，讀者可以想像王品企業體，旗下有多個餐廳，陶板屋、西堤、原燒等，每個餐廳都有每個餐廳折價券的玩法，此情境系統就如同上述一般。
在開發前，本身電商就存在折價券功能，但此功能為輸入序號後，判斷是否使用數量到達限制，如無，則可繼續使用，不與使用者綁定在一起；因此，此種折價券為非歸戶折價券。
非歸戶折價券的缺點在於不歸戶就可使用，因此一人可使用多次，畢竟系統認序號不認人，另一個缺點在於，使用者體驗性差，一定得手動複製序號。
因此，基於以上原因，衍生出歸戶折價券，那歸戶折價券的規格定義一下：
- 此種類型折價券，就算知道序號，沒歸戶就不能使用
- 歸戶折價券，只可歸戶一張折價券於同一個使用者身上
- 使用後的歸戶折價券，不會出現於使用者歸戶折價券列表中
基於規格，筆者加入 is_member_center & is_bind_user 兩個欄位，主因是會員中心折價券與電商折價券並不相同，可以想像集團發行的折價券(ex: 週年慶折價券)與電商發行的折價券(ex: 促銷站上季節商品折價券)，因此有了 is_member_center 欄位表示是否為會員中心發行，is_bind_user 則是表示是否此折價券設定為要綁定才可使用。
有了以上欄位與資料流程圖後，接下來就要來處理 API，程式細節不贅述。
- isMemberCenterCoupon
- 會員中心後台發送綁定名單前，會發 Request 作確認
- 目的為送資料前確認是否會員中心折價券
2. bindMemberVoucher
- 會員中心後台發送綁定名單與 Coupon Setting ID
- 目的為歸戶折價券並產出折價券序號，綁定至指定使用者身上
3. getVouchers
- 用途為使用者可查看自己身上有哪些折價券
- 瀏覽器發送 Request 詢問此使用者綁定折價券
4. getVouchersByCart
- 用途為使用者購買此購物車商品，可使用哪些綁定折價券
- 瀏覽器發送 Request 詢問此購物車可使用的綁定折價券，並回傳折價券折抵金額
5. sendOrderRecord
- 用途為訂單付款後，送資料給會員中心，處理成本認列相關問題
因此，完成這幾隻 API 後，撰寫 Unit Test，並與各部門整合測試後，就可以推上線，消費者就可以使用歸戶後的折價券囉！
會員等級與會員權益
想要完成會員階級相關的玩法，必須先完成會員等級的基礎設置。
問題來了！會員等級電商沒有資料，沒資料但要在電商落實會員相關玩法有兩種方式，一是每次都打 API 問，二是存在資料庫新開一張表，方法一當頻繁發送 Request 下不是個好方法，再加上後續要實作相關權益，不開一張表紀錄會員等級說不過去，最後選擇方法二。
在 Kick-Off 討論時，大家陷入折價券與會員權益的迷思，究竟兩者差在哪裡呢？沒差？ 有差？
- 沒差，拿歸戶折價券機制做：試想每個月要歸戶幾十萬的使用者，站在技術面上，要考慮到排程與錯誤處理機制，不是不行，就是伺服器負載高。
- 有差，差在哪裡：(1) 折價券一次性，一生一次序號 (2) 權益，每個循環週期會再次給予優惠喚回消費者 (3) 此週期權益會有頻次，ex: 一週三次
看來很明顯是有差，且差異蠻大的，這邊就有意識到，不能讓臭味道蔓延開來，必須讓其他部門知道，系統架構的重要性，系統架構如果一步思考錯，後面要救，確實有難度。
新打造一個會員權益機制，有什麼好處呢？
- 不依賴於折價券與歸戶機制下，不把折價券機制弄髒
- 依賴於會員等級，關聯階層簡單好懂
- 客製化玩法
下圖為消費者使用權益相關資料流程圖。
完成了資料流程與 Schema，接下來可以思考整個專案的技術需求 Todo-List!
為什麼要這樣做呢？一個大專案需求這麼多，Divde and Conquer，簡單但必要，畢竟一時片刻專案經理也不一定能列完所有 API，工程師盤點一下技術需求，避免漏網之魚。
- 會員等級與權益後台
- 目的為讓內部人員設定與管理權益的介面
- 需求要點：必須讓等級與權益關聯起來，白話一點，等級一有哪些權益，某某權益歸類於等級多少
- 對應 API：Level & Benefit CRUD 相關 API
2. 消費者前端顯示相關 API
- 目的為讓前端完成串接，將資料渲染顯示於瀏覽器
- 需求要點：一隻 API 是消費者手上所有權益、一隻 API 是根據購物車判斷消費者手上可適用的權益
- 對應 API：getBenefits(根據此使用者)、getBenefitsByCart(根據此使用者購物車)
3. 結帳權益後端邏輯
- 目的為檢查權益使用，如錯誤，不成立訂單，如正確，成立訂單，並寫入相關 Table
- 需求要點：檢查此權益剩餘次數，檢查此權益是否可用於這筆訂單等等邏輯確認
- 對應程式：計算權益使用於購物車驗證 / 計算權益於購物車折抵金額 Services
4. 會員中心後端與顯示 API
- 目的為串接各站權益與折價券做為會員中心所有站台權益與折價券集散地、後端還需回傳消費詳細資料，作為會計成本與帳務使用
- 需求要點：會員中心會員，但非電商會員，資料串接處理、回傳消費資料觸發時機與成本計算
- 對應程式： getMemberCenterBenefits API / Order info Job dispatch to Member Center
以上四個為主要的需求，其他的小細節，就不贅述。
實作方式，很開心終於有用到設計模式，這次運用設計模式中的簡單工廠模式，減少重複程式碼，細節呈現如下圖：
後端把資料結構與 API 處理完後，並撰寫好 Swagger 文件，接下來與前端討論如何串接，串接完成、兜完畫面，一切就大功告成！
溝通，那些大小事，如何白話工程技術
工程師不只是寫程式而已，這次專案範疇之大，跨行銷、財務、工程等不同部門，不是每個人都可以很快理解工程端的技術，當你的團隊與此次專案核心概念有代溝時，務必使用翻譯蒟蒻，讓團隊在同一個點上討論。
狀況一：非工程部門，不了解 A 功能與 B 功能差異，為什麼 B 功能不能用 A 功能解決？
Ans：筆者會建議用比喻法敘述一次，再使用圖示搭配情境說明，舉本次專案為例，非工程部門認為會員權益就是會員折價券，筆者遇到這個狀況，先使用餐廳做舉例，餐廳發給小明一張 2023/1/10 23: 59:59 到期的折價券，小明一生只能使用這張折價券一次；另一個情境，餐廳頒發小明為黃金會員，餐廳業者恭賀小明得到一個尊榮待遇，小明每年可以使用此黃金會員身份折價 100 元 2 次，此類優惠性質屬於權益，今年兩次，明年兩次，往後每年都是兩次。
筆者使用比喻法解釋後，再繼續說明如果使用折價券去做會員權益，會發生什麼後果，並闡述為何不要用折價券機制發送權益。
狀況二：畫面跟需求想像的不一樣，該怎麼辦？可否臨時加需求？需求突然想改，怎麼辦？
Ans：這類情況，已經非技術問題，此時此刻，也不該去花時間檢討誰對誰錯，工程師這時候化身為消防隊，消防隊不會在失火時，去探究起火原因，當下應該去專注如何解決問題、達成共識，尚未達成共識前，不要輕易埋頭修改程式碼，一切會做白工。
需求是否可修改與添加，取決於修改難易度與時程緊迫度，修改簡單或時程不趕，一切都好談；但修改困難、時程很趕，這部分工程師與專案經理頭應該很痛，當下應該無法想到最佳解，可以退而求其次，思考 work around 的方式，或是討論分階段修改，階段一完成哪些項目、階段二修改哪些項目，利用階段去達成最後的目標。
此外，鼓勵工程師在專案經理提出修改需求時，詢問修改這個需求的動機，瞭解為什麼要這樣改的原因，如當下無法確認此修改，請勿當下直接答應，提出 Survey and Trace Code 的時間，再進行回覆。如遇到修改困難或是需求調整不符合架構，勇敢說出執行困難點，並尋求雙方的共識。
狀況三：新增(修改) A 功能壞 B 功能，該怎麼辦？
Ans：當 Error Log 跳出錯誤，明明沒碰 B 功能，但它就炸裂了，工程師也不能揮一揮衣袖，不帶走一片雲彩，這樣太不負責任了！首先，先去理解與詢問 B 功能的作者與需求背景，瞭解 A 功能與 B 功能之間的連結，並討論誰負責修改，一起合作完成需求。
感想
加入公司以來，可以慢慢獨自承接一些較大的開發任務，從需求討論、系統設計、資料庫規劃、開發到上線需求，中間不單單是學習到技術面的養分，更多的是，溝通與團隊共識的達成。
共識，共識，共識！非常重要，古人說：千里之行，始於足下，這句話後面，還必須加上，動工之前，先確認需求。
在還沒達成需求與技術端的共識前，埋頭開發是相當危險的事情，工程師會陷入已經開發的沈沒成本，而導致無法客觀聆聽需求端的建議。
需求端與專案端，確認需求，必須責無旁貸，有任何不懂，都必須主動詢問，多問多瞭解，可以幫助共識的達成。
專案執行，就跟蓋房子一樣，行前討論，就像大家討論地基設計圖一樣，開發者將大家討論的設計圖，利用自身的技術能力一一實現，專案經理則負責尋求物料、資源、安排時程，需求端，也必須在設計、測試、驗收階段參與，避免瀑布流開發，導致後續修改重工成本，要知道地基修改是相當耗時的，團隊合作，每個人都必須各司其職，才能讓一個專案完成上線，很感謝大家的幫忙與協助，讓會員權益專案成功上線！
希望我的分享對讀者有些幫助，有任何問題可以 Email 與我聯絡，謝謝！
