• 菜雞行為：把看不順眼當技術債，把大重構當成進步
• STAR 階段：T (Task)
• 本篇定位：定義變更任務：找出不可破壞的外部契約、影響範圍與回復方式。

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

這篇在三日故事中的位置

Day 13｜我看不順眼的程式碼，就想整套重構，停在一張愈開愈長的整修清單。本篇只處理任務定義：該完成什麼、界線畫在哪裡；行動與結果留給 Day 15。

任務是安全地加上欄位，不是證明我的品味

虛構的粉鳥工單服務接著往下。冷靜下來，我重新問任務：「加上處理期限欄位」是要求，「順便整理模組」是我私心的方案，真正的任務是第三件事：不弄壞任何人現有的工作，把欄位安全加上去。下游還有建單的來源系統、產報表的排程與舊版客戶端，沒人要求重構，卻都可能被掃到。

這個欄位會流過誰的手

我先畫影響範圍，而不是先改程式：

[資料表] --> [工單服務] --> [API 回應]
                               |
                               +--> [舊版客戶端]
                               +--> [報表排程]

欄位從資料表流到 API 回應，下游各自解讀。這條鏈上，命名與分層是內部結構，改了只有我自己知道；資料表欄位、回應格式與欄位語意是契約，動了就是動到別人。必須先確認的未知：舊版客戶端遇到多出的欄位會不會壞、報表讀哪些欄位、空值給什麼預設值。哪套 ORM 比較優雅，可以無限期延後。

少改幾行不一定安全，界線畫在契約上

還有一個直覺要拆：「改得少就安全」。少改幾行若改在契約上，例如替舊欄位改名，殺傷力遠大於在模組裡多寫幾十行。界線因此不畫在行數，畫在契約：既有欄位與回應格式一個都不能動，新增的東西必須讓下游可以完全不知情；非目標寫明，不改名、不拆模組、不換套件；驗收是舊版客戶端與報表在不知情下照常運作，且動手前就有回復方式。未來要棄用舊欄位，得先談相容期與遷移，那是另一個任務。

先畫邊界，再談美感

要求、方案與任務分開；內部結構慢慢談，外部契約先守住；風險看碰了哪些契約，不看行數。

今天可以帶走的練習

替手上一項小變更花二十分鐘填一份《變更影響分析表》：列出修改點、上游、下游、公開契約、測試與回復方式。產出一頁分析表，另一位讀者能指出風險最高的一格即通過。只動內部實作、容易復原的改動不必填表。

對應工具：《變更影響分析表》。

# 變更影響分析表

用途：動手前追蹤修改點、相依、契約、測試與回復。
使用時機：變更會碰到資料表、API 或他人依賴的欄位時。
不必使用：只動內部實作、容易復原的小改動。

| 修改點 | 上游 | 下游 | 公開契約 | 測試 | 回復 |
| --- | --- | --- | --- | --- | --- |
| 新增期限欄位 | 建單來源 | 報表排程 | API 回應 | 舊版相容測試 | 移除欄位 |

提醒：填不出回復方式的變更，先不要動手。

下一篇

邊界畫好，剩下的是在界線內動手，以及那張整修清單的下場。Day 15｜我留下「現在不重構」的理由，反而更敢改。