第 22 日：主程式被「回收」的那一夜 — 從 Bug 回溯到完整測試

一、開場：誰偷了我的 main.go？

今天一開機、跑個 go run main.go，結果伺服器靜靜地拒絕啟動。
終端上沒報錯、沒 panic、沒警告——就像個沉默的同事。

結果一查版本控制歷史，真相大白：

有人（可能是我昨天的深夜自己 😭）在 merge 過程中 意外撤銷了 main.go 裡的新功能初始化。
Billing、Files、Batch 三個模組全被清空，imports 消失、service 沒建、handler 沒註冊。

這一刻，我彷彿聽見 Go compiler 在耳邊輕聲說：「你昨天不是 commit 嗎？怎麼今天變成空的？」

二、重建主程式：把消失的模組一個一個補回來

於是今天的第一個任務，就是「考古 + 復原」。
從 log 和 commit 訊息推回去，一步步重建出原本應該存在的初始化邏輯。

這段短短幾行，讓我感受到系統設計的重要性：只要初始化沒做好，整個 API 伺服器等於殘廢。

同時也順手修掉了之前一個小坑：RegisterHandlers() 的簽名不一致，呼叫時參數數量對不上。這次直接補上正確的函數呼叫，終於能順利編譯通過。

三、測試框架建設：從 0 到 1.3%

既然主程式都復原了，下一步自然是——寫測試！
今天正式建立了 基本單元測試框架。

🔧 採用技術

• 測試框架：testing + github.com/stretchr/testify/assert
• 測試文件：internal/api/services/basic_test.go、internal/api/services/service_test.go
• 目標：確保每個服務都有對應的構造與功能測試

📈 初始與結果

雖然數字看起來像個玩笑，但這 1.3% 是象徵性的突破——代表系統正式進入「可測試、可維護」階段。

✅ 已測功能

測試內容包括：字符串 / 數字 / 布林值驗證、請求與回應結構、錯誤邏輯與邊界條件。

四、資料庫遷移：011～013 版本上線

今天同時新增了三份 migration SQL：

三個 migration 一次執行成功，資料庫 schema 終於正式完整支援 Billing、File、Batch 三大模組。

這也意味著：從今天起，後端架構正式具備「企業級計費／檔案／批次發送」三要素。

五、API 全面驗證

執行 ./scripts/testing/test_api.sh 驗證結果如下：

整體來看，所有 API 都可正常呼叫，只是部分需額外參數驗證。

六、開發反思：從回收桶中救回一個系統

今天其實是一場救援行動。
main.go 被 rollback，services 消失、routes 全掛，連 database migration 都得重新跑。

但整體修復完後，我反而覺得這是一堂寶貴的課：

系統穩定性的第一步，是讓你的 main.go 永遠不再神秘消失。

這代表要：

• 建立 CI/CD 版本驗證
• 每次 commit 自動執行測試
• 強制 main 分支需通過檢查

同時，也要讓測試框架不再只是樣板。那 1.3% 不是結束，而是起點。

七、明日計畫

• 開始設計 排程發送機制（例如延遲通知 / 每日批次任務）
• 實作 Webhook 回調，讓外部系統能追蹤結果
• 製作 分析儀表板 API
• 強化 管理員介面，提供可視化查詢
• 增加 安全防護層：敏感資料過濾、加密欄位

八、今日小結

今天沒有新功能，也沒有 flashy demo。但在工程世界裡，能讓程式「正常啟動」就是最大的勝利。