今天要來介紹一個很多工程師嘴巴說重要、手上卻常常沒空做的東西：Refactor。筆者這次想做的，不只是示範 VS Code 跟 GitHub Copilot 怎麼協助 Refactor，而是想把一個很實際的觀念講清楚：AI 可以幫你動手，但是原則要自己控。

筆者整理了六個常見的 Refactor 訊號。這些不是教科書拿來考試的，是平常你打開專案、看兩眼就知道「嗯，該動刀了」的那種味道。

老實說，筆者自己超有感。因為去翻十幾年前寫的 code，真的是慘不忍睹啊… 邏輯、資料處理、格式、判斷，全部糊成一坨，但程式這樣混在一起就不太妙。那時候很常一個檔案寫到底，能跑就好；然後一段時間就會來討技術債 😭，幾點心得如下：

🧩 邏輯要拆清楚
商業邏輯、條件判斷、資料模型混在一起，改一處動全身，這就是筆者最想強調的，是商業邏輯要拆開這件事。以前很流行講鬆散耦合，講到後來有些人背得比做得熟，但它真的不是口號。你把業務規則、資料轉換、輸出顯示通通塞在一起，之後需求一改，整包一起抖，這就不是重構，是拆炸彈了啊。

Refactoring changes structure — not behavior。

這句話筆者很愛，重構不是改功能，而是把原本會動、但長得很阿雜的東西，整理成未來比較好維護的樣子。還有一個超常見的坑，就是 conditional logic。也就是 if / else if / else 寫到像樹枝岔開，最後長成一棵榕樹，讀的人先迷路，改的人先流汗。這種東西能不能改成更清楚的結構？很多時候其實是可以的~

🛠️ AI 能幫忙整理格式，但重構規則要先講清楚
筆者後來的做法，是先把自己的 Refactor 原則整理出來，請 AI 幫忙產一份 Markdown 規範檔。這招實務上非常實用，因為不是每次都從零開始提示，而是把你常用的標準先定義好，之後丟給 Copilot 參考。

其實這也很像帶新人：你不能只說「幫我改漂亮一點」，你要說清楚什麼叫漂亮、什麼叫不要碰、什麼叫拆分原則。AI 也是同樣道理。原則沒講，生成再快也只是把亂碼變成比較整齊的亂碼而已。

📘 AI 不是通靈：你不先定義 Refactor 原則，Copilot 只會依照表面結構去猜，不一定猜中你的維護意圖。

接著筆者準備了兩個 demo 來練手。第一個是 DataProcessor，很單純，就是把 item 跟 price 丟進來，先把字串做 Trim()，再把價格轉成 double。看起來沒什麼，對吧？但裡面故意塞了一段「其實多餘」的程式，像是先組一個 DataTable 再列印。

明明只有一筆資料，照理講直接印就好，根本不需要特地做一個 table。這段就是故意拿來測試：Copilot 在 Refactor 時，有沒有辦法辨識到這是多餘且重複思維的結構。

🔍 先看 VS Code 內建 Refactor，
在 VS Code 裡，本來就有一些傳統 Refactor 功能，例如萃取 class、封裝 property、抽出 interface 之類的。

另一個 demo，筆者是拿來測 槽狀 if-else 判斷，也就是付款方式那種分支很多的情境。這種東西最常出現在商業邏輯裡，平常很難避免，但至少可以讓它更清楚，不要讓整支 method 看起來像在種甘蔗，一節一節一直長。

更多實作請參考完整版影片

📌 今日結論：AI 很好用，但別把腦袋外包

這次做下來，筆者最大的感想是：GitHub Copilot 在 Refactor 這條路上，已經很好用了，但還不到你可以完全放空的程度。它能幫你省手工、補格式、提一些結構建議，甚至在某些情境下幫你快速拆分程式；可是真正要不要拆、拆成什麼樣、哪段才是商業核心，還是得靠你自己給出實作與驗證規範。