20251212 AI 時代的 Legacy Code 營救術 2025 WebConf

在軟體開發現場，面對沉澱多年的 Legacy Code，常常會陷入兩難：想改，又怕連帶影響整個系統；不改，又得持續承受技術債累積帶來的負擔。其實無論是在 AI 尚未普及的過去，還是今日各式 AI 輔助工具蓬勃發展，處理 Legacy Code 的核心原則始終如一——仍需要團隊共識、清晰流程以及足夠的驗證機制。然而在 AI 的協助下，我們能以更高的效率、更低的風險來面對這些挑戰。

本議程將會分享：

非 AI 時代 面對 Legacy Code 時的典型思考方式與策略。
AI 介入後，如何在重構與維護過程中發揮助力，提升理解、驗證與調整的效率。
來自實務經驗的觀察與建議，協助團隊在新舊並存的系統中更有信心地前進。

Transcript

1. AI 時代的 Legacy Code 營救術 陳佑 竹 aka. 墨嗓 @ AI 輔助下智慧重構原則與不變法則
2. • 陳佑 竹 • GitLab Hero • 資深系統分析師 • GitLab Taipei User Group / DevOps Taiwan / Laravel Taiwan 志 工 • mouson@gmail.com • https://gitlab.com/mo-playground • https://gitlab.com/mouson About Me
3. 世成科技
4. 世成科技 2014.07
5. 那段與 Legacy Code 相處的 日 子
6. 我們的軌跡 • Apache 1.3 • PHP 4.1.2 • 核 心 為使 用 C 編寫之 PHP Extension • PHP 程式碼超過千隻 PHP 程式 • LoC 超過 40 萬 行 (僅PHP) • 版本控制(CVS)服務損毀 • 非 PHP 原始碼遺落或不完整 • 使 用 非常 見 的商 用 資料庫 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2
7. 我們的軌跡 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2
8. 我們的軌跡 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2 PHP 5 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 2.2 5.2.17
9. 我們的軌跡 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2 PHP 5 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 2.2 5.2.17 PHP 7.3 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 .3
10. 我們的軌跡 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2 PHP 5 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 2.2 5.2.17 PHP 7.3 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 .3 PHP 7.4 Native Custom Extension PHP Extension Software Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.4 .4 8
11. 我們的軌跡 PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2 PHP 5 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 2.2 5.2.17 PHP 7.3 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.1 .3 PHP 7.4 Native Custom Extension PHP Extension Software Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 5.4 .4 8 PHP 8.2 Native Custom Extension PHP Extension Software Open Source 資料庫 Project Backend Frontend HTML, JavaScript, PHP ODBC Driver .2 9
12. 有機會 一 次變遷嗎？ PHP 4 Native Custom Extension PHP Extension Custom Software 6 Database Project Backend Frontend HTML, JavaScript, PHP ODBC Driver 4 1.3 4.1.2 PHP 8.2 Native Custom Extension PHP Extension Software Open Source 資料庫 Project Backend Frontend HTML, JavaScript, PHP ODBC Driver .2 9
13. 升級 PHP 8.2 -> 8.3 只花不到 一 天 PHP 8.3 Native Custom Extension PHP Extension Software Open Source 資料庫 Project Backend Frontend HTML, JavaScript, PHP ODBC Driver .3 9 PHP 8.2 Native Custom Extension PHP Extension Software Open Source 資料庫 Project Backend Frontend HTML, JavaScript, PHP ODBC Driver .2 9
14. 為什麼 Legacy 變 革 的路會這樣走？ 如果再走 一 次，AI 時代會怎麼走？
15. Legacy 為什麼變成 Legacy ?
16. 1. 技術債 為了追求速度 而 做出的權衡，長期下來累積利息
17. 1. 技術債 為了追求速度 而 做出的權衡，長期下來累積利息 為求快速 而 走捷徑 • 先求 生 存，先能跑就好 • 至 少度過了眼前的難關 • 程式碼再漂亮，組織倒 了也沒有意義
18. 1. 技術債 為了追求速度 而 做出的權衡，長期下來累積利息 為求快速 而 走捷徑 • 先求 生 存，先能跑就好 • 至 少度過了眼前的難關 • 程式碼再漂亮，組織倒 了也沒有意義 缺乏持續的組織與整理 • 團隊持續擴 大 ，但沒 人 可以 組織架構 • 省略測試、命名隨意、架構 妥協
19. 能不能 欠 技術債 ?
20. 能不能 欠 技術債 ? 承擔範圍內、還的起可以 欠 。但要記得還。
21. 2. 需求變更 並非開發者的錯， 而 是環境必然的改變
22. 2. 需求變更 並非開發者的錯， 而 是環境必然的改變 產品需求的改變 • 產品的需求變更 • 規格新增、修改或刪除
23. 2. 需求變更 並非開發者的錯， 而 是環境必然的改變 產品需求的改變 • 產品的需求變更 • 規格新增、修改或刪除 環境變化 • 環境或底層硬體變遷 • 硬體更新後不適 用 • 可擴充性不 足 • 預期 支 援100 人 上線， 結果來了 100,000 人
24. 2. 需求變更 並非開發者的錯， 而 是環境必然的改變 產品需求的改變 • 產品的需求變更 • 規格新增、修改或刪除 環境變化 • 環境或底層硬體變遷 • 硬體更新後不適 用 • 可擴充性不 足 • 預期 支 援100 人 上線， 結果來了 100,000 人 外部依賴更新 • 外部函式庫的依賴
25. 可以怎麼開始 ?
26. 一 個可參考的重構框架 成功的重構，像蓋 一 棟建築，需要規劃、執 行 及維護 Refactoring at Scale 大 規模重構
27. 一 個可參考的重構框架 成功的重構，像蓋 一 棟建築，需要規劃、執 行 及維護 1. 勘查與測量 3. 施 工 與打造 2. 建立藍圖 4. 啟 用 與維護 • 用 數據取代臆測，作為後續 決策判斷的基礎 • 制定執 行 計畫、設定 里 程碑 並取得團隊共識 • 在嚴謹的流程下，有紀律的 執 行 原始碼變更 • 確保變 革 能深入團隊 文 化， 並防 止 未來的品質衰退
28. 1. 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎
29. 1. 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。
30. 1. 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。 程式碼覆蓋率 • 盡可能地開始增補測試：單 元測試、整合測試、E2E測 試 • 測試覆蓋率 高 ，重構的過程 才能盡可能的降低風險。
31. 1. 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。 程式碼覆蓋率 • 盡可能地開始增補測試：單 元測試、整合測試、E2E測 試 • 測試覆蓋率 高 ，重構的過程 才能盡可能的降低風險。 原始碼靜態分析 • 複雜度分析 • 執 行 路徑分析 • 原始碼品質分析 • 弱點掃描
32. 1. 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。 程式碼覆蓋率 • 盡可能地開始增補測試：單 元測試、整合測試、E2E測 試 • 測試覆蓋率 高 ，重構的過程 才能盡可能的降低風險。 原始碼靜態分析 • 複雜度分析 • 執 行 路徑分析 • 原始碼品質分析 • 弱點掃描 CI 持續整合CD持續部署 • 建立持續整合、持續部署環 境 • 讓數據分析變為 日 常 • 即早發現、即早治療
33. 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。 我們的實作 • 重新建立版本控制，使 用 • 建立內部 Issue Tracking System • 建立研發團隊 工 作流程
34. 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 版本控制及數據分析 • 有記錄才能開始有分析。 • 變更頻率：檔案的變頻率、 次數 高 的可能優先 目 標。 • 共同變更分析：經常被同時 修改的，代表有 一 定的耦合 度，需要進 一 步分析。 我們的實作 • 重新建立版本控制，使 用 • 建立內部 Issue Tracking System • 建立研發團隊 工 作流程 AI 世代 • 版本控制系統是基本需求，無法避免。 • 但可以選擇更 方 便與 AI 協作的系統與 工 具。
35. 我們的實作 • 建立單元測試、整合測試、E2E 測試 • 先從核 心 、重要的開始 • 盡可能地開始增補測試：單 元測試、整合測試、E2E測 試 • 測試覆蓋率 高 ，重構的過程 才能盡可能的降低風險。 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 程式碼覆蓋率
36. 我們的實作 • 建立單元測試、整合測試、E2E 測試 • 先從核 心 、重要的開始 • 盡可能地開始增補測試：單 元測試、整合測試、E2E測 試 • 測試覆蓋率 高 ，重構的過程 才能盡可能的降低風險。 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 程式碼覆蓋率 AI 世代 • 搭配 Copliot 協作建立測試案例
37. 原始碼靜態分析 • 複雜度分析 • 執 行 路徑分析 • 原始碼品質分析 • 弱點掃描 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 我們的實作 • 靜態分析 工 具導入 • 程式碼複雜度分析 (EX: PHPLoc, PHPQA, PhpMetrics) • 原始碼安全及品質分析 (EX: SonarQube) • SBOM 分析
38. 原始碼靜態分析 • 複雜度分析 • 執 行 路徑分析 • 原始碼品質分析 • 弱點掃描 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 我們的實作 • 靜態分析 工 具導入 • 程式碼複雜度分析 (EX: PHPLoc, PHPQA, PhpMetrics) • 原始碼安全及品質分析 (EX: SonarQube) • SBOM 分析 AI 世代 • 依然使 用 靜態分析 工 具執 行 ， 而 不是直接請 AI 建議 • 相對有 一 個穩定 一 致的參考依據 • 太燒 Token • 但根據分析結果，與 Copilot 協作改善調整
39. CI 持續整合CD持續部署 • 建立持續整合、持續部署環 境 • 讓數據分析變為 日 常 • 即早發現、即早治療 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 我們的實作 • 建立單元測試、整合測試、E2E 測試
40. CI 持續整合CD持續部署 • 建立持續整合、持續部署環 境 • 讓數據分析變為 日 常 • 即早發現、即早治療 我們的實作 與 AI 世代的 勘查與量測 用 數據取代臆測，作為後續決策判斷的基礎 我們的實作 • 建立單元測試、整合測試、E2E 測試 AI 世代 • 與 AI 協作建立團隊適 用 的 Pipeline
41. 2. 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識
42. 2. 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 建立終局狀態及 里 程碑 • 描述重構完成後，系統應有的 樣貌。不只是「更好」， 而 是 量化數據。 • 不是 一 次到位， 而 是 一 個 一 個 的 里 程碑累積。
43. 2. 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 建立終局狀態及 里 程碑 • 描述重構完成後，系統應有的 樣貌。不只是「更好」， 而 是 量化數據。 • 不是 一 次到位， 而 是 一 個 一 個 的 里 程碑累積。 取得利害關係 人支 持 • 你的主管可能不 支 持 • 他們不直接寫程式，無法切 身 感 受痛苦 • 他們的績效評估指標跟 工 程師不 同：新功能 VS. 原始碼品質 • 需要轉化為各種量化數據：速 度、 工 時折現 金 額等呈現價值。
44. 2. 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 建立終局狀態及 里 程碑 • 描述重構完成後，系統應有的 樣貌。不只是「更好」， 而 是 量化數據。 • 不是 一 次到位， 而 是 一 個 一 個 的 里 程碑累積。 取得利害關係 人支 持 • 你的主管可能不 支 持 • 他們不直接寫程式，無法切 身 感 受痛苦 • 他們的績效評估指標跟 工 程師不 同：新功能 VS. 原始碼品質 • 需要轉化為各種量化數據：速 度、 工 時折現 金 額等呈現價值。 找到對的夥伴 • 主題專家： • 理解領域知識、背景的專家，提 供諮詢。 • 共創者： • 核 心 開發者，認同藍圖、願意 一 起努 力 的 人 。
45. 建立終局狀態及 里 程碑 • 描述重構完成後，系統應有的 樣貌。不只是「更好」， 而 是 量化數據。 • 不是 一 次到位， 而 是 一 個 一 個 的 里 程碑累積。 我們的實作 與 AI 世代的 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 我們的實作 • 建立 目 標架構藍圖 • 建立各階段 目 標，分階段實施
46. 建立終局狀態及 里 程碑 • 描述重構完成後，系統應有的 樣貌。不只是「更好」， 而 是 量化數據。 • 不是 一 次到位， 而 是 一 個 一 個 的 里 程碑累積。 我們的實作 與 AI 世代的 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 我們的實作 • 建立 目 標架構藍圖 • 建立各階段 目 標，分階段實施 AI 世代 • 團隊與 Copilot 協作，找出最適合的 行 動路線
47. 取得利害關係 人支 持 我們的實作 與 AI 世代的 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 我們的實作 • 轉譯各種讓非技術背景 人 員也同感技術描述 • 量化各種數據及影響分析 • 你的主管可能不 支 持 • 他們不直接寫程式，無法切 身 感 受痛苦 • 他們的績效評估指標跟 工 程師不 同：新功能 VS. 原始碼品質 • 需要轉化為各種量化數據：速 度、 工 時折現 金 額等呈現價值。
48. 取得利害關係 人支 持 我們的實作 與 AI 世代的 建立藍圖 制定執 行 計畫、設定 里 程碑並取得團隊共識 我們的實作 • 轉譯各種讓非技術背景 人 員也同感技術描述 • 量化各種數據及影響分析 AI 世代 • 團隊與 Copilot 協作，善 用 「請以非技術 人 員、 高 中 生 能懂的語 言 」等 Prompt，快速建立同感的內容。 • 你的主管可能不 支 持 • 他們不直接寫程式，無法切 身 感 受痛苦 • 他們的績效評估指標跟 工 程師不 同：新功能 VS. 原始碼品質 • 需要轉化為各種量化數據：速 度、 工 時折現 金 額等呈現價值。
49. 3. 施 工 與建造 在嚴謹的流程下，有紀律的執 行 原始碼變更
50. 3. 施 工 與建造 在嚴謹的流程下，有紀律的執 行 原始碼變更 一 次 一小 步 • 每次只變更 一小 部分 • 更容易 Review • 更容易追蹤 • 遇錯更容易還原
51. 3. 施 工 與建造 在嚴謹的流程下，有紀律的執 行 原始碼變更 一 次 一小 步 • 每次只變更 一小 部分 • 更容易 Review • 更容易追蹤 • 遇錯更容易還原 測試、測試、再測試 • 重構的前提是 行 為不變。 • 所以修改前，需有 足 夠的測 試保護。 • 每次變更後，即立即執 行 測 試。
52. 3. 施 工 與建造 在嚴謹的流程下，有紀律的執 行 原始碼變更 一 次 一小 步 • 每次只變更 一小 部分 • 更容易 Review • 更容易追蹤 • 遇錯更容易還原 測試、測試、再測試 • 重構的前提是 行 為不變。 • 所以修改前，需有 足 夠的測 試保護。 • 每次變更後，即立即執 行 測 試。 Pair Programming • 傳遞知識、減少錯誤 • 不 見 得是開發者 一 起協作， 可以是懂領域知識的 PM 與 能開發的開發者。
53. 3. 施 工 與建造 在嚴謹的流程下，有紀律的執 行 原始碼變更 一 次 一小 步 • 每次只變更 一小 部分 • 更容易 Review • 更容易追蹤 • 遇錯更容易還原 測試、測試、再測試 • 重構的前提是 行 為不變。 • 所以修改前，需有 足 夠的測 試保護。 • 每次變更後，即立即執 行 測 試。 Pair Programming • 傳遞知識、減少錯誤 • 不 見 得是開發者 一 起協作， 可以是懂領域知識的 PM 與 能開發的開發者。 持續追蹤各種指標 • 測試覆蓋率 • 複雜度分析 • 執 行 路徑分析 • 原始碼品質分析 • 弱點掃描
54. 我們的 開發流程
55. 我們的 開發流程
56. 我們的 開發流程
57. 我們的 開發流程
58. 我們的 開發流程
59. 我們的 開發流程
60. 我們的 開發流程
61. 我們的 開發流程
62. 我們的 GitLab Pipeline
63. 開發執 行 實務 - 1 初期 • 透過各種 方 法了解系統結構 • 透過新需求了解程式架構 • 撰寫 文 件
64. 開發執 行 實務 - 2 日 常 • 持續針對重要核 心 演算法重構、補上測試 • 累積研發團隊 Credit • 錯了代表以測試所描述的規格還不夠完整 • 補測試後就不會再錯，不再改 A 壞 B
65. 開發執 行 實務 - 2 日 常 • 持續針對重要核 心 演算法重構、補上測試 • 累積研發團隊 Credit • 錯了代表以測試所描述的規格還不夠完整 • 補測試後就不會再錯，不再改 A 壞 B • 程式 又
66. 開發執 行 實務 - 2 日 常 • 持續針對重要核 心 演算法重構、補上測試 • 累積研發團隊 Credit • 錯了代表以測試所描述的規格還不夠完整 • 補測試後就不會再錯，不再改 A 壞 B • 可能不是程式寫 錯， 而 • 程式 又
67. 開發執 行 實務 - 3 轉換期 • PHP 版本升級 • 語法相容性轉換 • 語法檢驗 工 具導入 • 搭配好 用 的 IDE • 導入框架 • Legacy 改寫 • PHP Extension 核 心 改寫
68. 4. 啟 用 與維護 確保變 革 能深入團隊 文 化，並防 止 未來的品質衰退
69. 4. 啟 用 與維護 確保變 革 能深入團隊 文 化，並防 止 未來的品質衰退 知識傳承與教育 • 工 作坊：體驗新的 方 法，並解答疑問。 • 技術分享會：分享專案成果與獲得，擴 大 影響 力 。 • 建立知識庫： • 指南及常 見 問答 • 歷史脈絡的呈現
70. 4. 啟 用 與維護 確保變 革 能深入團隊 文 化，並防 止 未來的品質衰退 知識傳承與教育 • 工 作坊：體驗新的 方 法，並解答疑問。 • 技術分享會：分享專案成果與獲得，擴 大 影響 力 。 • 建立知識庫： • 指南及常 見 問答 • 歷史脈絡的呈現 用 DevOps 文 化建立防護網 • 鼓 勵 日 常 小 型重構：順 手 整理視為開發過程， 而 非額外的 工 作。 • 重視設計討論及 Code Review：視為知識分享與 共同提升品質的機會。 • 持續不斷的讓系統、成員 自 我進化
71. 將持續改進融入 文 化 一 次成功的重構能解決過去的問題 但 一 種持續改進的 文 化能確保未來的成功
72. 軟體開發 版本規劃 組譯 測試 產品釋出 發佈部署 維運 監控
73. 讓每 一 次的 Commit 都是 一 次改善的機會 https://www.facebook.com/groups/DevOpsTaiwan/posts/5610989525654714/
74. 為什麼 Legacy 變 革 的路會這樣走？ 如果再走 一 次，AI 時代會怎麼走？
75. 為什麼 Legacy 變 革 的路會這樣走？ 如果再走 一 次，AI 時代會怎麼走？ 善 用 AI 的 大 量記憶及執 行 效率的特性可以加快重構， 但軟體開發的基礎原則不會有太 大 的改變
76. Q&A