真實的恐懼
打開 IDE。
檔案名稱：OrderProcessor.java
滾動條拉到底，要 5 秒。
游標停在第 1 行，右下角顯示：4,127 lines
搜尋 if，847 個結果。
這個 function 處理所有訂單邏輯。每天跑 10 萬次。改錯一行，整個訂單系統會爆。
沒有註解。 沒有文件。 原作者三年前離職了。
你的任務：「改一下訂單折扣的邏輯。」
看起來很簡單。
但你連折扣邏輯在哪都找不到。
這個場景，你經歷過幾次？
為什麼 Legacy Code 這麼難
表面問題 vs 真正問題
| 你以為的問題 | 真正的問題 |
|---|---|
| Code 太長 | 不知道哪段重要、哪段是歷史垃圾 |
| 沒有註解 | 不知道「為什麼」這樣寫 |
| 原作者離職 | 沒人能回答「這樣改會不會爆」 |
| 看不懂 | 沒有安全感，不敢動 |
Legacy Code 的三層恐懼
第一層：認知負荷
4000 行 code，你要同時記住： – 這段在做什麼 – 變數從哪裡來 – 會影響什麼 – 有什麼邊界條件
人腦的工作記憶大約 7 個項目。4000 行遠遠超過負荷。
第二層：不確定性
你改了第 2847 行。
會影響什麼？不知道。 有沒有其他地方依賴這裡？不知道。 有測試可以驗證嗎？沒有。
不確定性會放大恐懼。
第三層：責任壓力
改壞了是你的鍋。
即使這 code 不是你寫的， 即使這 code 本來就是地雷， 出事的時候，大家會問：「誰改的？」
這三層恐懼疊在一起，導致一個結果：
不敢動。
能不改就不改。 能繞過就繞過。 能拖延就拖延。
然後 code 越來越爛，下一個人更不敢動。
惡性循環。
AI 能幫什麼：判斷框架
不是所有事情都要交給 AI。 也不是所有事情都要自己來。
✅ AI 完全接手
解釋 code 在做什麼 – 翻譯機：把 4000 行變成 20 段摘要 – 你不用逐行讀，看摘要就能掌握全貌
找出相依性 – 這個 function 讀了哪些 DB table – 呼叫了哪些外部 API – 改了會影響什麼
找出潛在問題 – null pointer 風險 – 效能瓶頸 – 安全漏洞
產生測試案例 – Happy path – 邊界條件 – 錯誤處理
建議拆分方式 – 可以拆成哪幾個 function – 先拆哪個最安全
這些是「有標準答案」的事情。AI 比人快、比人全面。
🤝 人機協作
確認 AI 的理解是否正確
AI 會猜錯業務邏輯。
它不知道「為什麼這裡要乘以 1.05」。 它不知道「這個 workaround 是為了處理某個大客戶的特殊需求」。
你需要驗證 AI 的說法，補充它不知道的 context。
決定拆分的優先順序
AI 說可以拆成 7 個 function。 先拆哪個？後拆哪個？有哪個不能動？
這需要你判斷業務優先級和風險。
審核測試案例
AI 產生的測試可能漏掉關鍵場景。 你要審核、補充、確認涵蓋率。
❌ 人來決定
這段邏輯該保留還是刪除
看起來沒用的 code，可能是某個 edge case 的處理。 刪不刪，是業務決策，不是技術決策。
重構的時機
現在改還是等下個 sprint？ 這個風險值不值得承擔？ 團隊有沒有 bandwidth？
跟 PM/主管溝通
為什麼要花時間重構？ 對用戶有什麼好處？ 不做會怎樣？
這些 AI 沒辦法幫你。
第一步：建立認知地圖
在改任何東西之前，先搞清楚這坨 code 的全貌。
讓 AI 當翻譯
不要一次丟 4000 行給 AI。它會崩潰，你會得到一堆廢話。
分段餵。
第一輪，給全貌：
這是一個電商系統的 processOrder function，
總共 4000 行，我會分段給你。
先告訴你整體結構：
- 第 1-400 行：訂單驗證
- 第 401-800 行：庫存檢查
- 第 801-1200 行：運費計算
- 第 1201-1800 行：折扣處理
- 第 1801-2500 行：付款處理
- 第 2501-3200 行：建立出貨單
- 第 3201-4000 行：發送通知
你先理解這個結構。第二輪，深入單一段落：
現在我給你第 1-400 行（訂單驗證）。
請告訴我：
1. 這段的主要邏輯，用一句話說明
2. 列出 3-5 個主要步驟
3. 有什麼潛在問題
4. 這段跟後面的庫存檢查怎麼銜接AI 會回答：
這段在做訂單驗證，確保訂單可以進入處理流程。
主要步驟：
1. 檢查用戶登入狀態
2. 驗證購物車不為空
3. 檢查商品是否還在架上
4. 驗證收件地址格式
5. 檢查是否有未完成的訂單
潛在問題：
- 第 45 行：user.getCart() 沒有 null check
- 第 120 行：地址驗證是寫死的 regex，可能跟不上格式變化
- 第 380 行：有個 magic number 1.05，不知道是什麼
銜接方式：
驗證通過後，會把 validatedOrder 物件傳給庫存檢查。重複這個過程，你會得到 20 個段落的摘要。
現在你有了「目錄」。
讓 AI 畫相依圖
分析這個 function，列出它：
1. 讀取了哪些資料庫表
2. 呼叫了哪些外部 API
3. 使用了哪些全域變數或設定
4. 會修改哪些狀態（DB、快取、檔案）為什麼這很重要？
知道碰了什麼，才知道改了會影響什麼。
這是你的「爆炸半徑評估」。
讓 AI 找地雷
檢查這段 code，找出：
1. 潛在的 bug（null pointer、邊界條件、race condition）
2. 效能問題（N+1 query、重複計算、大量迴圈）
3. 安全風險（SQL injection、權限檢查缺失）
4. 可維護性問題（magic number、重複邏輯、過深巢狀）這不是要你現在修，是要你知道地雷在哪。
踩到地雷之前，先知道地雷的位置。
第二步：先有測試，再動手改
核心原則：沒有測試的重構是自殺
你改了 4000 行中的第 2847 行。
怎麼知道沒改壞？
跑一次看看？ 手動測幾個場景？ 祈禱？
這不是工程，這是賭博。
三種測試策略
策略 A：Golden Master Testing（最保守）
概念：先錄下現有行為，重構後比對結果是否一致。
步驟：
1. 準備 50 組真實的輸入資料（從 production log 撈）
2. 跑一次現有 code，記錄所有輸出
3. 這就是你的「黃金標準」
4. 重構後，再跑一次，比對輸出是否完全一樣
5. 有任何不一樣，就是改壞了讓 AI 幫你產生測試資料：
根據這個 function 的參數，
產生 20 組涵蓋不同情境的測試輸入：
- 5 組正常情況（一般訂單）
- 5 組邊界條件（空購物車、單一商品、大量商品）
- 5 組特殊情況（有折扣碼、跨境訂單、預購商品）
- 5 組錯誤情況（無效地址、庫存不足、付款失敗）策略 B：Characterization Testing（描述現狀）
概念：不管 code 對不對，先把「現在的行為」變成測試。
這個 function 目前的行為：
- 輸入 X 會回傳 Y
- 輸入 A 會拋出 B 例外
- 輸入 null 會回傳空陣列
把這些行為寫成測試。
不管它是不是 bug，先鎖定現狀。為什麼？
重構的目標是「行為不變」。 先鎖定現狀，之後再討論要不要改行為。
策略 C：針對關鍵路徑測試（務實）
如果沒時間寫完整測試：
這個 function 最重要的 5 個使用情境是什麼？
只針對這 5 個情境寫測試。80/20 法則：20% 的測試涵蓋 80% 的風險。
有總比沒有好。
AI 產生測試的陷阱
AI 產生的測試有常見問題：
問題 1：只測 happy path
AI 會產生「正常流程」的測試，但漏掉邊界條件。
問題 2：Mock 太多
AI 會把所有外部相依都 mock 掉，結果測試只測了「mock 的行為」，沒測到真實整合。
問題 3：斷言太弱
// AI 產生的測試
assertNotNull(result); // 只確認不是 null，沒驗證內容你要做的：審核 AI 的測試
問 AI：
你剛才產生的測試，有沒有漏掉什麼重要情境？
特別是：
- 資料為空的情況
- 資料量很大的情況
- 併發執行的情況
- 權限不足的情況
- 外部服務超時的情況讓 AI 自己檢查自己。
第三步：拆分策略
為什麼會變成 4000 行
4000 行的 function 不是一天變成的。
成因 1：功能堆疊
每次加需求，就往裡面塞一段。
「這裡順便加一下 A 功能。」 「那裡也加一下 B 檢查。」
三年後，變成 4000 行。
成因 2：Copy-paste
類似的邏輯，複製 10 次。
「這個跟那個差不多，複製過來改一下。」
每次複製，行數翻倍。
成因 3：恐懼驅動
不敢新開 function，怕改壞現有的呼叫。
「就塞在這裡好了，反正能跑。」
成因 4：沒有 Code Review
沒人說「這太長了」。 沒人說「應該拆開」。 沒人關心 code quality。
理解成因，才知道怎麼拆。
讓 AI 建議拆分方式
這個 4000 行的 function，請建議如何拆分。
考量：
1. 單一職責原則（一個 function 做一件事）
2. 可測試性（拆完要能單獨測試）
3. 最小化改動範圍（盡量不影響呼叫端）
請告訴我：
1. 可以拆成哪幾個獨立的 function
2. 每個 function 的職責是什麼
3. 它們之間怎麼呼叫
4. 哪個最獨立、最適合先抽出來AI 會給你類似這樣的建議：
建議拆成 7 個 function：
1. validateOrder() - 訂單驗證（第 1-400 行）
職責：確保訂單資料完整、用戶有權限
相依：最低，只需要 Order 物件
建議順序：第一個抽
2. checkInventory() - 庫存檢查（第 401-800 行）
職責：確認所有商品有足夠庫存
相依：需要 validateOrder 的結果
3. calculateShipping() - 運費計算（第 801-1200 行）
職責：根據地址和商品計算運費
相依：需要驗證後的地址資料
...拆分的三個原則
原則 1：先抽最獨立的
哪段跟其他段落最沒有相依？先抽那段。
問 AI：
這 7 個建議的 function 中，
哪一個跟其他部分相依性最低？
我想從最安全的開始拆。通常是： – 純計算的邏輯（不讀 DB、不呼叫 API） – 驗證類的邏輯（只檢查不修改） – 通知類的邏輯（最後一步，不影響主流程）
原則 2：漸進式替換（Strangler Fig Pattern）
不要一次全改。
步驟：
1. 新建一個 validateOrder() function
2. 把原本第 1-400 行的邏輯複製過去
3. 在原本的位置，改成呼叫 validateOrder()
4. 跑測試，確認行為一致
5. Commit
6. 下一個 sprint 再抽下一段每次只動一小塊。 每次都可以 rollback。 每次都有測試保護。
原則 3：保持 function signature 不變
重構第一階段：只改內部結構，不改輸入輸出。
為什麼？ – 呼叫端不用改 – 測試不用改 – 風險最小
等內部結構穩定了，再考慮要不要調整介面。
第四步：處理「只有離職的人知道」的邏輯
AI 也會遇到的黑洞
有些 code，AI 也看不懂：
// 不知道為什麼要這樣，但拿掉會出事
price = price * 1.05 * 0.97 * 1.02;你問 AI，它會說：
「這看起來是在調整價格，但我不知道為什麼是這些數字。可能是稅率、折扣、或其他業務規則。」
這就是業務邏輯黑洞。
AI 能幫你分析 code 結構，但它不知道： – 這是哪個客戶的特殊需求 – 這是為了繞過哪個歷史 bug – 這是誰在三年前的某個凌晨三點加的 workaround
考古策略
策略 1：Git Blame
git blame -L 2847,2847 OrderProcessor.java找到是誰、什麼時候加的這行。
git show abc123 # 看那個 commit 的完整內容
git log --grep="price adjustment" # 搜尋相關的 commit message運氣好的話，commit message 會寫原因。 運氣更好的話，會有 issue 或 ticket 編號。
策略 2：找相關文件
問 AI：
這段 code 提到了 'specialDiscountRate'。
幫我在專案中搜尋相關的：
1. 設定檔（application.yml、config.json）
2. 文件（README、wiki、confluence）
3. 測試案例（可能有註解說明用途）
4. 其他 code 的註解策略 3：找老員工
不是找他解釋 code，是找他講歷史。
「2021 年那個大客戶的專案，有沒有什麼特殊的定價邏輯？」
「這個 1.05 的數字，你有印象是什麼嗎？」
他可能不記得 code，但可能記得業務背景。
策略 4：標記並隔離
如果真的找不到答案：
/**
* WARNING: 不明的定價調整邏輯
*
* 可能與 2021 年某客戶專案相關（待確認）
* 原作者 John 已離職，無法詢問
*
* 在確認前請勿修改
* 如需修改，請先跟 PM 確認業務規則
*
* 發現日期：2025-12-08
* 發現人：Tim
* 相關 ticket：找不到
*/
price = price * 1.05 * 0.97 * 1.02;至少下一個人知道： – 這是「已知的未知」 – 不是你的疏忽 – 動之前要小心
心態篇：這不是你的問題
Legacy Code 是歷史共業
這 4000 行不是你寫的。
當初會這樣寫，有當初的原因： – 時程很趕 – 需求一直變 – 沒有人 review – 沒有時間重構
你的責任是「讓它變好一點」，不是「讓它完美」。
重構的三個陷阱
陷阱 1：想一次重構完
「我要花兩週把這整個重寫！」
結果： – 兩週後沒寫完 – 新需求進來，要在舊 code 上改 – 你的重構 branch 跟 main 差了 500 個 commit – 永遠 merge 不回去
正確做法：每次進去，改一小塊，馬上 merge。
陷阱 2：追求「乾淨」
你花了三天把 code 變漂亮。
PM 問：「使用者感受到什麼改變？」
你：「呃…沒有，但 code 變乾淨了。」
PM：「…」
正確做法：重構要跟著需求走。
要改那塊功能時，順便整理那塊 code。 這樣重構就是「做需求的一部分」，不是「額外的工作」。
陷阱 3：重構變重寫
「這 code 太爛了，重寫比較快。」
90% 的情況，這是錯的。
重寫意味著： – 丟掉所有 edge case 處理（你不知道有哪些） – 丟掉所有 bug fix（你不知道修過什麼） – 重新踩一次所有的坑（前人踩過你還要再踩）
重寫的誘惑很大，但代價更大。
Boy Scout Rule
童軍規則：
「離開營地時，讓它比你來的時候乾淨一點。」
每次改 code： – 順手改一個變數名稱，讓它更清楚 – 順手抽一個小 function，讓邏輯更明確 – 順手加一行註解，讓下一個人少猜一點
不是大重構。 就是順手。
一年後，4000 行變成 3000 行。 不是某次重構的功勞，是每天一點點的累積。
實戰操作：Claude Code 完整對話流程
起手式：給 AI 足夠的 Context
錯誤做法：直接貼 4000 行
你：幫我解釋這段 code
[貼 4000 行]AI 會崩潰或給你一堆廢話。
正確做法：分層餵食
你：我要接手一個 legacy 專案。
有個 processOrder function，4000 行。
我會分段給你。
先告訴你背景：
- 這是電商系統的訂單處理核心
- 每天跑 10 萬次
- 原作者已離職
- 沒有測試、沒有文件
我的目標是：
1. 先理解它在做什麼
2. 找出風險點
3. 規劃怎麼拆分重構
你準備好了嗎？五個最實用的 Prompt 模板
模板 1：程式碼翻譯
用一句話說明這段 code 在做什麼。
然後用 bullet points 列出 3-5 個主要步驟。
不要解釋語法，專注在業務邏輯。模板 2：相依性分析
分析這個 function：
1. 輸入：需要什麼參數、從哪裡來
2. 輸出：回傳什麼、會改變什麼狀態
3. 相依：讀寫哪些 DB table、呼叫哪些外部服務
4. 副作用：會發 email？寫 log？改全域變數？模板 3：風險評估
如果我要修改第 2847 行的這個邏輯：
1. 可能影響哪些其他地方？
2. 需要注意什麼邊界條件？
3. 你建議我先寫哪些測試來保護這次修改？模板 4：測試案例生成
針對這個 function，設計測試案例：
1. Happy path：3 個正常流程
2. Edge cases：3 個邊界條件
3. Error cases：3 個錯誤處理
每個案例說明：輸入、預期輸出、測試目的模板 5：重構建議
這個 function 太長了，請建議拆分方式：
1. 可以拆成哪幾個獨立的 function？
2. 每個 function 的職責是什麼？
3. 它們之間怎麼呼叫？
4. 哪個最獨立、最適合先抽出來？完整對話範例
你：我要接手一個 legacy 專案，有個 processOrder function 4000 行。
我先給你前 200 行，請幫我理解。
[貼 code]
AI：這段是訂單驗證邏輯，主要做五件事：
1. 檢查用戶登入狀態
2. 驗證購物車不為空
3. 檢查商品是否還在架上
4. 驗證收件地址格式
5. 檢查是否有未完成的訂單
潛在問題：
- 第 45 行的 null check 可能漏了 edge case
- 第 120 行的地址驗證是寫死的 regex
你：第 45 行那個 null check 具體是什麼問題？
AI：第 45 行是 user.getCart().getItems()。
如果 getCart() 回傳 null，會拋出 NullPointerException。
建議加上 null check 或使用 Optional。
你：好，我想先處理這段。幫我寫測試案例。
AI：[產生 5 個測試案例]
你：這些測試有涵蓋到你說的第 45 行的問題嗎？
AI：沒有，讓我補充一個測試 cart 為 null 的案例...
你：現在給你第 201-400 行...重點：對話是迭代的，不是一次問完。
AI 答錯的時候怎麼辦
AI 會猜錯，特別是：
- 業務邏輯：它不知道你公司的規則
- 命名誤導：function 叫
validate但其實在做transform - 歷史 workaround：看起來是 bug，其實是故意的
怎麼處理：
你：你說這段在做 X，但我實際跑起來發現是做 Y。
可能的原因是什麼？
請重新分析，考慮到 [你的觀察]。讓 AI 修正自己，而不是換一個問題問。
團隊協作：怎麼帶 Junior 一起處理 Legacy Code
Junior 面對 Legacy Code 的困境
他們卡住，不是因為懶或笨。
是因為： – 沒有足夠的 context：不知道系統全貌，不知道為什麼這樣設計 – 沒有安全感：怕改壞、怕被罵、怕問蠢問題 – 沒有方法論：不知道從哪開始、不知道怎麼拆解問題
Pair Programming with AI
新的 pair programming 模式：
Senior + Junior + AI（三人組）
流程：
1. Senior 給 context：「這個 function 是訂單核心，碰了會影響營收」
2. Junior 跟 AI 對話，Senior 旁聽
3. AI 解釋 code，Junior 發問
4. Senior 在關鍵時刻介入：「AI 這邊說的不對，實際上是...」
5. Junior 學到的不只是 code，還有 Senior 的判斷邏輯好處：
- Senior 不用一直解釋基礎概念（AI 處理）
- Senior 可以專注在「AI 不知道的事」（業務邏輯、歷史脈絡）
- Junior 有 AI 當安全網，敢問問題
- Junior 看到 Senior 怎麼跟 AI 協作，學到方法論
建立 Legacy Code 知識庫
每次處理 legacy code 後，留下紀錄：
## OrderProcessor.java 探索紀錄
### 2025-12-08 by Tim
- 理解了第 1-400 行（訂單驗證）
- 發現第 45 行有潛在 null pointer
- 已補上測試案例 3 個
- 未解之謎：第 380 行的 magic number 1.05 是什麼
### 2025-12-15 by Amy
- 問了前輩 John，1.05 是 2021 年某客戶的特殊稅率
- 已加上註解說明
- 抽出 validateOrder() function，行數 400 → 80
### 2025-12-22 by Tim
- 處理了第 401-800 行（庫存檢查）
- 發現有 N+1 query 問題，但這次不修，先記錄這樣知識就不再只在一個人腦袋裡。
下一個人進來，先看這份紀錄，就知道前人做了什麼、發現了什麼。
Code Review 的新標準
以前的 review 標準：「這段 code 寫得對不對？」
現在的 review 標準：「這段 code 讓系統更容易維護了嗎？」
新的 review checklist：
有寫測試嗎？（至少 happy path）
有改善可讀性嗎？（變數命名、抽 function）
有留下註解嗎？（特別是非直覺的邏輯）
改動範圍是否最小化？（不要順便大重構）
如果是 legacy code，有更新知識庫嗎？
向上管理：怎麼說服主管給你時間處理 Legacy Code
主管不關心「Code 很髒」
你說：「這個 function 4000 行，維護性很差，需要重構。」
主管聽到：「你想花時間在不會產生新功能的事情上。」
你需要翻譯成主管的語言。
三種說服框架
框架 1：風險語言
這個 function 處理所有訂單，每天跑 10 萬次。
目前沒有測試、沒有文件、原作者離職了。
上次出問題，花了 12 小時才定位到 bug。
如果週末出事，沒人能快速處理。
建議投資 3 天做基礎整理：
- 加上關鍵路徑的測試
- 寫一份結構說明文件
- 標記已知的風險點
這樣下次出問題，處理時間可以從 12 小時降到 2 小時。框架 2：效率語言
上次改訂單折扣邏輯，預估 2 天，實際花了 5 天。
其中 3 天是在：
- 讀懂 4000 行 code（1.5 天）
- 手動測試確保沒改壞（1 天）
- 修改過程中踩到的坑（0.5 天）
接下來三個月有 5 個需求會動到這塊。
如果我們花 3 天整理：
- 每個需求可以省 2 天
- 三個月省 10 天
- ROI：3 天投資，10 天回報框架 3：人才語言
新人 Amy 加入團隊 1 個月了。
訂單模組她還不敢碰，因為 code 太複雜、沒有文件。
對比之下，用戶模組有測試有文件，她第二週就能獨立改了。
如果我們不整理訂單模組：
- 永遠只有我能改這塊
- Amy 成長速度受限
- 我沒辦法休假（因為沒人能 backup）不要一次要太多時間
錯誤：「我需要兩週專心重構這塊。」
主管會說：「等有空再說。」
然後永遠不會有空。
正確：「每個 sprint 我花半天整理一小塊，跟著需求走。」
主管容易同意，而且你真的會做。
展示進度
每次整理完，發一個簡短的更新：
本週整理了 processOrder 的訂單驗證段落：
- 抽出 validateOrder()，350 行 → 80 行
- 補上 5 個測試案例
- 下次改這塊預估可省 2 小時
累積進度：4000 行已整理 400 行（10%）讓主管看到： – 你在做什麼 – 有什麼具體成果 – 對團隊有什麼好處
技術債量化：怎麼跟非技術人員解釋
類比：房子的隱藏成本
想像你買了一間 30 年的老房子。
看起來能住，但是：
- 電線老舊，偶爾跳電
- 水管鏽蝕，水壓不穩
- 沒有圖紙，每次裝修都要猜管線在哪
你可以繼續住，但：
- 每次出問題，修理費越來越高
- 師傅不敢動，怕牽一髮動全身
- 有一天可能整個系統崩潰
技術債就是這樣。
系統能跑，但維護成本越來越高。
每次改東西，風險越來越大。三個量化指標
指標 1：修復時間（Time to Fix）
上次訂單系統出 bug：
- 定位問題：8 小時（在 4000 行裡面找）
- 修復問題：2 小時
- 測試驗證：2 小時（手動，因為沒有自動測試）
總計：12 小時
如果有測試和文件，預估只需要 4 小時。指標 2：變更成本（Cost of Change）
上次改訂單折扣邏輯：
- 需求本身：改 10 行 code
- 實際花費：5 天
時間去哪了：
- 讀懂 code：2 天
- 手動測試：1 天
- 踩坑修復：1 天
- 實際修改：0.5 天
- Code review + 部署：0.5 天
有測試的模組，同樣的需求只要 1 天。指標 3：新人上手時間（Onboarding Time）
Amy 加入團隊 1 個月：
- 用戶模組：第 2 週能獨立開發（有測試、有文件）
- 支付模組：第 3 週能獨立開發（有測試、缺文件）
- 訂單模組：1 個月了還不敢碰（無測試、無文件、太複雜）
每個新人都要重新踩坑。視覺化呈現
畫一張簡單的圖給主管看：
模組健康度儀表板
用戶模組 ████████░░ 80% ✓ 有測試、有文件
支付模組 ██████░░░░ 60% △ 有測試、缺文件
訂單模組 ██░░░░░░░░ 20% ✗ 無測試、無文件 ← 風險最高主管一眼就知道問題在哪。
建立技術債清單
不要只抱怨「code 很爛」。建立一個具體清單：
| 項目 | 風險等級 | 預估整理時間 | 整理後效益 |
|---|---|---|---|
| processOrder 無測試 | 高 | 3 天 | 修復時間 -8 小時/次 |
| 用戶模組無文件 | 中 | 1 天 | 新人上手 -1 週 |
| 支付 API 無錯誤處理 | 高 | 2 天 | 減少客訴、降低退款率 |
| 報表模組效能差 | 低 | 5 天 | 查詢時間 30 秒 → 3 秒 |
有清單，才能討論優先級、排進 roadmap。
完整流程總結
Week 1：建立認知
目標：知道這坨 code 在幹嘛、有什麼風險
- 讓 AI 解釋每一段在做什麼 → 產出：段落摘要
- 讓 AI 畫出相依圖 → 產出：dependency map
- 讓 AI 找出地雷 → 產出：風險清單
產出物：一份「系統地圖」文件
Week 2：建立安全網
目標：有足夠的測試保護，才敢動手改
- 產生 Golden Master 測試資料
- 讓 AI 產生測試，你審核補充
- 確保關鍵路徑有測試覆蓋
產出物：測試覆蓋率從 0% → 30%+（關鍵路徑）
Week 3+：漸進式改善
目標：每次進去，讓它比之前好一點
- 從最獨立的段落開始抽
- 每次只改一小塊，馬上 merge
- 標記無法理解的邏輯，不要硬改
- 更新知識庫，留給下一個人
產出物：每個 sprint 減少 5-10% 的 code 行數
從恐懼到掌控
以前打開 4000 行：
- 腦袋當機
- 不知道從哪開始
- 改了怕爆
- 想離職
現在：
- AI 當翻譯，你看摘要
- AI 畫地圖，你知道邊界
- AI 寫測試，你有安全網
- AI 建議拆法，你決定順序
那 4000 行還是 4000 行。
但你不再害怕了。
因為你有方法。 因為你有工具。 因為你知道，這不是你的問題，是歷史共業。
你的工作，是讓它一點一點變好。
不是英雄式的大重構。 是每天一點點的 Boy Scout Rule。
一年後回頭看，4000 行變成 2000 行。 有測試、有文件、有人敢改。
那就是你的功勞。