• 菜雞行為：把看不順眼當技術債，把大重構當成進步
• STAR 階段：S (Situation)
• 本篇定位：呈現我如何把陌生、醜或不合偏好的程式碼直接判定為技術債。

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

這篇在三日故事中的位置

上一組故事收在 Day 12｜我補上失敗情境後，測試才開始像真的。這一組更難察覺：把看不順眼當技術債，把大重構當成進步。本篇先停在情境，任務的定義留給 Day 14。

需求只要加一個欄位，我卻先開出整修清單

這種衝動我自己犯過不只一次，細節放進虛構的「粉鳥工單服務」，不對應真實公司、人物或專案。需求很小：工單要多一個「處理期限」欄位。打開模組，迎面而來是八百行的服務類別、不合我習慣的命名、手寫 SQL 與層層回呼。欄位還沒加，筆記已寫滿另一件事：拆模組、統一命名、換 ORM、重寫整條資料流。清單愈列愈有使命感，原本的交付卻一步沒往前。

「遲早要還的債」讓整套重寫聽起來像負責任

當時這一切很好辯護。技術債的說法我聽過：現在偷懶，以後加倍奉還。既然都要動這個模組，順手整理乾淨不正是負責任嗎？問題不在動機，而在我始終沒回答：這筆債現在讓誰付利息？我拿不出這段程式害誰變慢、出錯或不敢改的紀錄，手上只有一句「看了很痛苦」。

看不順眼裡混著四種不同的東西

回頭看，我把四種不同的東西全倒進技術債這個桶子：

技術債需要成本、風險或未來影響的證據，而我手上只有情緒。看不懂也不等於設計有罪，多半只代表我還沒讀懂當年限制。重構可以有價值，但得回答「為什麼是現在」，而不是「我剛好路過」。

先要求債提出證據

本篇不定義該怎麼判，只先立三條規矩：動手前分清眼前是偏好、瑕疵、限制還是債；說它是債，就要說得出利息記在哪裡；重構的價值用現在的需求與風險回答，不用美感回答。

今天可以帶走的練習

挑一段你看不順眼的程式碼，用《技術債判定表》把感受拆開：哪些是偏好、哪些是瑕疵、哪些有成本與風險的證據。產出一頁分類表，另一位讀者能指出哪一項值得排進工作即通過。問題極小、口頭可確認時不必填表。

對應工具：《技術債判定表》。

# 技術債判定表

用途：判斷一項不理想設計是否正在造成可觀察損失。
使用時機：想把「看不順眼」排進工作之前。
不必使用：問題極小、口頭確認就足夠時。

| 項目 | 目前問題 | 實際成本 | 發生頻率 | 風險 | 證據 |
| --- | --- | --- | --- | --- | --- |
| 手寫 SQL | 閱讀困難 | 尚無紀錄 | 低 | 待評估 | 無 |

提醒：拿不出成本與證據的項目，先當偏好，不當債。

下一篇

欄位終究得加。動手前該判斷的不是美感，而是改動會碰到什麼。Day 14｜我該先判斷的是風險、契約和改動邊界，會把小需求重新定義成能安全完成的任務。