• 菜雞行為：把看不順眼當技術債，把大重構當成進步
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何選擇局部修改、隔離、重構或暫緩，並留下重新評估條件。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 14｜我該先判斷的是風險、契約和改動邊界，留下界線清楚的任務：不動外部契約，把期限欄位安全加上去。本篇交代我怎麼做、留下什麼。

我先把欄位加成舊契約看不見的樣子

虛構案例接著走。我沒有先開整修清單，而是照影響分析動手：新欄位可為空、附預設值，資料表用可回復的方式加欄位，既有 API 回應照舊，只在新版介面多回傳一個欄位；舊版客戶端與報表不必知道這件事。那段讓我痛苦的手寫 SQL，只在必經之路包一層薄查詢函式，新邏輯寫在函式後面，其餘一行沒動。

整修清單逐項四選一，不准無條件重寫

接著輪到清單，每一項都要挑一個選項，不准無條件重寫：

暫緩不是丟掉。我把整套重構寫進《重構決策紀錄》，載明當時資訊、不採用理由與重新評估條件：再因難改而返工，或新需求撞上架構限制，就重新開議。

結果是交付和重構不再互相綁架

結果沒有戲劇性：欄位交付了，舊契約沒有壞，本來就該如此。真正的改變是質性的：我不再用整套重寫換心理上的乾淨，因為「現在不重構」的理由白紙黑字在那裡，隨時可被推翻；下次再看不順眼，先翻紀錄看條件成立了沒有，不必重新吵一次。留下的證據是那份紀錄、包住舊碼的查詢函式與相容測試。限制也得說：決策仍可能錯，暫緩可能讓債長大；薄函式層是多出的維護成本；紀錄要有人回頭讀才有用。

粉鳥工程筆記：把「不做」也寫成一個決策

每次重構衝動都先過四選一；暫緩要寫理由與重新評估條件；只順手修交付路徑上的瑕疵；紀錄是留給未來推翻自己用的，不是護身符。

今天可以帶走的練習

挑一個一直想重構卻沒動手的模組，用半小時，以《重構決策紀錄》寫「現在不重構」決策：填上當前需求、問題證據、方案與重新評估條件。產出一頁紀錄，驗收方式是另一位讀者能看懂為何現在不做、何時該重談。順手就能改完的小整理不必立案。

對應工具：《重構決策紀錄》。

# 重構決策紀錄

用途：記錄為什麼重構、局部處理或暫緩。
使用時機：重構衝動與交付搶時間、決策需要留下理由時。
不必使用：順手就能改完、不影響他人的小整理。

| 當前需求 | 問題證據 | 方案 | 決策 | 重新評估條件 |
| --- | --- | --- | --- | --- |
| 新增期限欄位 | 僅閱讀不適 | 全面重構／暫緩 | 暫緩 | 再因難改返工時 |

提醒：理由只寫當時知道的事；決策可以被未來推翻。

下一篇

這組故事收在一份敢把「不做」寫下來的紀錄。下一種學生味換到溝通：Day 16｜我以前的提問，只是一張問題轉交單。