前幾天完成了新增任務與瀏覽器持久化，昨天又替現有功能補上最少且必要的測試。
現在程式可以運作，也有測試保護重要行為，終於可以開始討論重構。
今天不增加任何產品功能，而是請 Codex 找出一個範圍小、改善明確的維護性問題，在外部行為不變的前提下整理程式。
重構是調整程式內部結構，但不改變外部可觀察行為。
對目前的 Issue Tracker 來說，重構前後都應該維持：
如果重構順便加入編輯功能、改變錯誤訊息或重新設計畫面，那就不再只是重構。
功能修改和重構混在同一個 diff 時，Reviewer 很難判斷某一行改變是為了新需求，還是只調整程式結構。
一旦測試失敗，也不容易分辨原因來自行為變更或重構。
把兩者分開有幾個好處：
目前專案仍然很小。有些程式雖然可以抽成函式、hook 或 service，卻不一定已經造成維護問題。
值得優先處理的訊號包括：
「可以拆」不等於「現在應該拆」。如果 Codex 只能說新的架構比較乾淨，卻無法指出目前的具體問題，這次可以選擇不重構。
開始前，我會先確認：
這些結果是重構前的行為基準。
如果測試原本就失敗，應該先釐清原因，而不是讓 Codex 在紅燈狀態下開始搬動程式。
我會開一個新的 Codex 任務，先要求分析、不修改：
目標：
請分析目前 Issue Tracker 的可維護性，找出範圍小、改善明確的重構機會。
這次只分析，不要修改任何檔案。
請先閱讀：
- AGENTS.md
- 目前的產品程式
- localStorage 持久化邏輯
- 現有測試
- 最近新增功能與測試的 Git 歷史
請找出具體問題，例如：
- 重複邏輯
- 過長或責任混雜的函式／元件
- 儲存與畫面邏輯過度耦合
- 不清楚的命名或資料流
- 會提高下一個功能修改風險的結構
對每項 finding 說明：
1. 檔案與行號
2. 目前造成的具體維護成本
3. 建議的最小重構方式
4. 預計影響的檔案
5. 如何證明外部行為沒有改變
6. 風險與不值得現在處理的理由
最後只推薦一個最適合這次執行的重構。
如果目前沒有足夠明確的機會，請直接說明，不要為了完成任務而製造抽象層。
先要求 findings，是為了讓「要不要重構」本身也接受 Review，而不是一開始就授權 Codex 大幅整理專案。
收到分析後，我會用下面幾個條件選擇：
| 判斷項目 | 問題 |
|---|---|
| 具體性 | 能指出目前程式中的實際問題嗎？ |
| 影響 | 能降低理解或修改成本嗎？ |
| 範圍 | 能在少量檔案內完成嗎？ |
| 行為 | 能保持 UI、資料與錯誤行為不變嗎？ |
| 驗證 | 現有測試能保護這次調整嗎？ |
| 時機 | 現在處理比等到功能增加後更合理嗎？ |
這次只選一個，不把所有「可以改善」的地方打包成大型重構。
如果建議是把 localStorage 的讀寫與解析從畫面元件中分離，就要說明它能改善什麼，例如讓元件主要負責互動與呈現，或讓未來修改儲存方式時不必碰觸畫面流程。
但實際採用哪個 finding，仍然要以 Codex 對目前 repository 的分析為準。
人工確認其中一項後，再繼續輸入：
請只實作剛才確認的那一項重構。
要求：
- 遵守 AGENTS.md
- 不改變任何使用者可觀察行為
- 不新增功能、套件或設定
- 不修改文案、樣式與資料格式
- 不處理其他 findings
- 優先使用最少的檔案與最小 diff
- 每個主要步驟後執行相關測試
- 如果發現必須改變外部行為才能完成，請停止並說明
開始前先記錄目前測試、lint 與 build 結果。
完成後再次執行相同驗證，並回報：
1. 實際修改的檔案與結構變化
2. 重構前後如何對應
3. 為什麼外部行為沒有改變
4. 重構前後的測試、lint 與 build 結果
5. 和原計畫是否有差異
6. 仍存在但這次刻意不處理的問題
這段 Prompt 明確要求只處理核准的 finding。否則 Codex 看到附近還有其他可整理的程式，很容易讓重構範圍一路擴大。
這是我的 repo，在裡面的 commit 找到 "reconstruct" 就是這篇文章寫完時的狀態。
最後從 diff 再確認一次：
這次如果只是內部重構，原本以使用者行為為主的測試通常不需要跟著大改。若大量測試都必須重寫，可能代表測試過度耦合，也可能表示重構其實改變了外部介面。
今天沒有要求 Codex 全面整理程式，而是先找出有證據的維護性問題，再選擇一個範圍小、改善明確的重構機會。
iThome鐵人賽
看影片追技術