# 商戶管理後台(Platform Page)：重構排程 (AKI)
<!-- ### 【A部分】 畫面及狀態管理:
一個Page估約1-2天 (未加串接API、不含 i18n)
**共 25 + 5 (OTC入口) = 約估 30 個任務**

#### 開發說明：
* USDT 買賣入口：
內含四個分頁 + 購買USDT的交互及紀錄等，故需較長開發時程。初估**4-5天**

* 购宝平台转出G币、銀行卡設定、申请G币充值补币、交收款项、商户G币互转：
這 5 個頁面多有CRUD的功能交互 & 用戶狀態設定較多，每個頁面皆需 **2天** 進行開發

> 1/18的14點為止：已完成 6 個任務 / 未完成 21 個任務
> 預計花費：21*2 = 42 個工作天內

### 【B部分】 串接後端 API (預計過年後串) :
一個Page估約 0.5 天
**共 25 + 5 (OTC入口) = 約估 30 個任務**

> 1/18的14點為止： 未完成 27個任務 (皆尚未與後端串接)
> 預計花費：27 * 0.5 = 14個工作天內 -->

## 進度排程：

> 平均一個 feature 評估需要 2 天
有 10 個標記 🕐 表示「CRUD的功能交互多、狀態設定、商業邏輯較複雜」，則需耗費 4 天

🚀 20 x 2 + 10 x 4 = **60 個工作天 ▶ 約 4 個月**

### 開發說明：
-- 🕐 表較為耗時

▼ 2/2 追加- 集團頁面:商戶總覽
- [x] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 主控版
- [x] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 商户推播QR Code **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 商户设置
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 余额查询 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 登入纪录 **[進行中]** << 引用 Ryan 的
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 会员绑定列表 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ ~~角色管理~~ => R#1400

▼ 統計報表
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 存提款歷程
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 购宝平台转出G币 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 挂单出售G币 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 掛單出售-進行中
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 掛單出售-已完成
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 掛單出售-失敗
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ G幣收發歷程
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 銀行卡設定 🕐 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 申請G幣補幣 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 申請G幣回收
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 交收款項 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 商戶G幣互轉 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 營運管理 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ 會員出款
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT買賣入口: 整體架構 🕐 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT買賣入口: otc交易 🕐 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT買賣入口: 購買紀錄 🕐 **[進行中]**
- [X] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT買賣入口: 出售紀錄 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT買賣入口: 錢包 🕐
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT權限管理
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT兌換
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

▼ USDT兌換紀錄
- [ ] 畫⾯
- [ ] 串接api
- [ ] 商業邏輯

### 目前進度

>1/31 進度回報：
共有 30 個任務(feature)，其中 10 個進行中，20 個尚未啟動

---

## 補充 (by Aki)：

### 🙋‍♀️為什麼想重構？
#### 1. 伴隨系統架構異動的歷史，專案內多處重複的判斷式
-> 嚴重耦合
例如 單一角色的USDT權限調整，可能會影響到整個SPA的路由
#### 2. 專案架構欠缺模組化
-> 改A壞B
例如 站內餘額的有2種，因應商業邏輯的重複須逐一修改 feature
#### 3. 部分相依套件已不再維護、版本過舊
-> 新需求對應衝突
-> 若需導入新技術，可同時進行評估。
例如 圖表套件是否更適合 React 框架使用的，能提升開發效率?
如需更換也需要判斷他與現行 library 是否有衝突&需要一起更新

#### 4. 檢視 [code smell](https://antongunnarsson.com/react-component-code-smells/) 進而改善
-> 代碼優化 & 利於未來導入單元測試 OR E2E測試
-> 減少人力QA的成本 及 RD對【團隊代碼】的掌握度提升

#### 5. 雖為管理後台，於使用者體驗方面仍有進步的空間
-> 商戶client端使用者體驗佳，能減少客服/QA/研發單位提出各種小bug
-> 提升公司運作整體工作效益

---

### 🔍能夠做的有什麼 及 預期效益？
#### 1. 對應2023年最新的商業邏輯面，調整架構/定義屬性
(而非 2019+2020+2021 這樣分別規劃的分散式開發)
#### 2. 對專案進行模組化的工程 (打好基礎建設)，提升複用性及效率
#### 3. 相依套件的更新，於重構時進行再適合不過。適合藉此統一評估
#### 4. 未來團隊成員無論誰加入，都能夠易於讀懂且能對導入測試打下基礎
#### 5. 優化使用者體驗 (UI畫面)，不僅能與業主合作順利，也為公司減少不必要成本

---

### 🛠 目前已經做了什麼

#### 1. 路由設定模組化
#### 2. 樣式管理模組化
#### 3. 總共約 XX 個 feature，目前 XX 個已在進行中
... 等等

### 🚀 大概要花多久時間
20 x 2 + 10 x 4 = 60 個工作天 ▶ 約 4 個月 (AKI)