下一步要寫什麼？Blog 主題備忘錄

備忘錄性質：本文記錄待撰寫的文章主題，不定期更新。已完成的文章直接移除。

兩份備忘錄的分工：本篇收「從專案 git 歷史可挖的技術主題」（Legacy PHP、資料正確性、業務邏輯）； Claude Code 工具鏈與需要個人素材的主題請見可考慮的主題。

去識別化：本檔不寫真實 issue 編號與機構名稱，素材出處只記「模組 + 時間」，需要時用 git log --grep 反查即可。實際動筆時仍須完整套用 docs/CLAUDE_ANONYMIZATION_MAP.md。

🥇 首選：業務規則寫死的代價

見下方第 1 項。CI/CD 系列已全數完成，桌面那份 12 週規劃的素材已用盡。

資料正確性與業務邏輯（第一手素材）

1. 業務規則寫死的代價：從硬編補助比例到讀取設定值

素材：2026-08 個案費用清單兩個修正——自負比例改讀自付額度（修正自費個案被算出政府補助）、身分別紀錄取不到時改退回當月最新一筆而非寫死預設比例；另有 2026-07~08 電子發票匯出多次計價邏輯調整
核心議題：「取不到資料時該 fallback 到哪一筆」是計費系統的真正設計題——退回預設值、退回最近一筆、還是直接報錯？
為什麼值得寫：多數文章談「別寫魔術數字」，很少談 fallback 語意選錯會產生什麼帳務後果

2. 一個匯出功能的四次修法與最終退版

素材：2026-07 打卡紀錄修改頁的匯出 Excel，依序經歷
1. 按鈕無反應 → 改用 POST 分段送出
2. 列表改為每頁 1000 筆，匯出與篩選改走資料層以涵蓋全部資料
3. 查詢與匯出限制日期區間最多一個月，並在頁面加註說明
4. 最後整支 Revert 回修改前狀態
為什麼值得寫：真實的「修不動就縮需求、縮了還是退版」決策過程，比成功故事更有參考價值

3. 需求推翻自己：流水號改共用，兩週後又改回獨立

素材：2026-08 個案案號先從各家獨立改為三家共用（並在新增與匯入建檔端補上查重），兩週後又改回三家各自獨立
核心議題：可逆設計。改動涉及既有資料的編碼規則時，怎麼讓「改回去」不是災難
為什麼值得寫：需求反覆是常態，但很少人寫怎麼在程式結構上預留退路

4. Legacy 系統的權限模型長成什麼樣

素材：2026-07 人員基本資料依權限等級與人事分類控管檢視權；2026-08 督導無法查看其他人的服務紀錄清單
為什麼值得寫：接續〈2319 處機構分支〉，講另一種 if 分支的來源——權限判斷如何在十年間長成無人敢動的結構

5. 客製條件被誤刪又補回：客製化的回歸風險

素材：2026-07 需求摘要及照護計畫表單頁「補回」某機構的客製條件；同期個案結案摘要客製列印版身分別空白，改為與編輯版同語意的整組 fallback
為什麼值得寫：〈2319 處機構分支〉的實戰續篇——客製化不只難維護，改共用邏輯時還會靜默壓掉某一家的行為

舊清單（仍未動筆，素材已在 git 裡）

6. Legacy PHP 表單模板化重構：拆解千行大檔案

素材：大規模模板化重構（5+ commits）、抽取共用渲染模板、3,000 行檔案重構為獨立函式、表單檢視頁拆分 + AJAX lazy loading
為什麼值得寫：大檔案重構是 Legacy 維護最常見的任務

7. Duplicate Key 錯誤的根因分析：多租戶架構的資料衝突

素材：重複上傳產生重複記錄的根因追蹤、預檢 duplicate key + 空字串日期解析、第三方檢核出現重複資料
為什麼值得寫：多租戶文章的延伸，根因分析過程有教學價值

8. Legacy PHP 整合 S3 雲端儲存

素材：圖片 src 支援 S3、圖片上傳欄位消失 + 清除鍵、S3 CLASS 的緊急修復
為什麼值得寫：從本地檔案到雲端的遷移是常見需求

9. 建立簽核系統：跨模組的共用功能設計

素材：建立共用 function，逐步套用至計劃、紀錄、評估表等多個模組
為什麼值得寫：共用功能的設計與漸進式套用策略

建議優先順序

優先	主題	理由
1	業務規則寫死的代價	fallback 設計是原創切角
2	匯出功能的四次修法與退版	真實失敗歷程，稀缺題材
3	客製條件被誤刪又補回	熱門文章的續篇，受眾現成
4	Duplicate Key 根因分析	多租戶文章延伸
5	表單模板化重構	大檔案重構受眾廣

✅ 已完成：〈罕用字地獄：一個姓名讓整份 Excel 報表錯位的三層追查〉（2026-08-18） 「十年 Legacy 專案導入 Git 工作流」系列四篇（2026-08-15 ~ 08-18）：（一）診斷與分支模型 · （二）CI 第一階段：零誤報 · （三）SQL Migration 版本化 · （四）部署、回滾與 E2E