06 / WORK / CASE STUDY
高科大設備借用管理系統
條碼借還、盤點、賠償與用餐基金記帳的系所內部系統;2025 年起獨立開發並部署。
- TYPE
- FULL STACK
- SCOPE
- 已部署 · 獨立開發
- STACK
- DJANGO · DRF · MYSQL · REACT · PLAYWRIGHT
- LINKS
- LIVE
01 / PROBLEM
系所的設備借還原本依附在一套舊平台的模組上,資料髒、難維護;「用餐基金」則是一份人工維護的 Excel。這個系統同時承接兩件事:把設備借還(含逾期、賠償、盤點、套組)系統化,並把基金記帳轉成有帳戶餘額、結算期間與現金核對的正式帳。
02 / CONSTRAINTS
- 要承接舊系統資料庫,舊借用紀錄大量欄位為空、品質差。
- 櫃檯借還是高頻操作、使用者非技術背景,單筆流程必須在幾秒內完成。
- 單台 VPS、無容器與 Redis:快取用行程內 LocMemCache,速率限制改用 DB cache 以跨 worker 共享。
03 / ARCHITECTURE
Django 5 + DRF 模組化單體,依領域切成 13 個 app(borrowing、finance、audit、inventory、kits⋯),27 個資料模型、23 個資源路由加 86 個自訂 action;前端 React 19 + Ant Design,40 個頁面。JWT 放 HttpOnly cookie 並做 refresh rotation 與 blacklist;RBAC 以 Role/Capability 建模。
稽核是獨立子系統:middleware 自動記錄操作(含敏感操作標記、耗時、回應狀態),另有欄位級的模型變更記錄。財務子系統做用餐基金:交易寫入時自動維護帳戶餘額,支援結算期間與現金核對,整套帳可從原始 Excel 一鍵匯入重建。
04 / RESPONSIBILITIES
前後端獨立開發(git 全歷史單一作者,2025/09–2026/07):資料模型、API、權限、React 前端、測試策略與部署(nginx + gunicorn systemd)。
05 / CHALLENGES → SOLUTIONS
CHALLENGE
舊系統的借用紀錄要搬進新 schema,但資料髒到直接匯入必然失敗。
SOLUTION
寫了一組遷移工具(每個實體一個 mapper、獨立 verifier、支援 dry-run 與報表),舊庫以獨立 connection 隔離。一次實跑 180 秒搬入 9,138 筆借用單、3,336 名學生與 370 件設備;同時有 2,271 筆舊紀錄因空欄位報錯——這批錯誤被完整留在遷移報表裡,成為列管中的資料品質債,而不是被吞掉。
CHALLENGE
櫃檯要快:人工輸入太慢,而且桌機與手機的掃描硬體完全不同。
SOLUTION
整條流程條碼化:後端以 Code128 產生設備標籤,前端依裝置自動切換模式——桌機走掃碼槍輸入、手機開相機(@zxing),支援批次連掃與同碼短時間去重,一掃帶出設備與借用單。
CHALLENGE
用餐基金的 Excel 有多年新舊資料混雜,轉成正式帳不能弄丟一筆。
SOLUTION
寫成兩遍式匯入命令:第一遍建帳戶與收支類別,第二遍處理期初餘額、結算期間與逐筆交易,整體包在資料庫交易裡,支援 dry-run 與重跑;交易寫入自動維護餘額,月底有現金核對機制。
06 / SYSTEM FACTS
13
領域模組
86
自訂 API actions
1,112
後端測試函式
36
Playwright E2E
07 / LESSONS
遷移的防呆要做在 mapper 層:2,271 筆錯誤幾乎全是同一種空欄位問題,先清洗再匯入,整份錯誤報表就不會存在。
把錯誤靜默成「一切正常」比壞掉更危險。後期 UIUX 稽核點出的重複頁面與假資料顯示,是快速堆功能階段留下的債——現在有清單、有編號地在還。
08 / SCREENS
以下畫面皆為示範(mock)資料,不含任何真實使用者資料。
NEXT
大型 Django 微服務全通路商務平台