Logo
Published on

AI 程式碼會製造大量技術債嗎？ Modern Software Engineering 深度分析

隨著 AI 程式碼生成工具如 GitHub Copilot、Cursor、Windsurf 等越來越普及，開發者們開始思考一個關鍵問題：這些看似神奇的工具會不會在提升開發效率的同時，也為我們的程式碼埋下大量的技術債？在 Modern Software Engineering 頻道的深度討論中，兩位業界專家 Trisha Gee 和 Steve Smith 提出了令人深思的觀點。

AI 會製造技術債嗎？答案是肯定的

在「Modern Software Engineering」頻道的「一大問題 (One Big Question)」系列中，主持人 Trisha Gee 與 Equal Experts 的全球現代化與平台主管 Steve Smith 針對「AI 是否會製造大量的技術債？」這個問題進行了深入探討。兩位專家一致認為答案是肯定的，但同時也強調這個問題是可以透過適當的方法來減輕的。

為什麼 AI 會製造技術債？

Steve Smith 開宗明義地表示，AI 程式碼製造技術債是「不可避免的」現象。Trisha Gee 也強烈認同這個觀點，並提出了兩個核心原因：

1. 程式碼產出速度與數量

AI 工具能夠以前所未有的速度生成大量程式碼。從統計學的角度來看，當程式碼量大幅增加時，產生技術債的可能性自然也會隨之提高。這就像是在高速公路上行駛，速度越快，出現意外的風險就越高。

2. 生成程式碼的品質問題

目前生成式 AI 所產出的程式碼品質，在預設情況下往往未能達到理想的業界標準。這並非 AI 技術本身的問題，而是與其訓練資料和應用方式有關。

AI 作為「火箭燃料」的雙面性

Steve Smith 用了一個非常生動的比喻：他將生成式 AI 比作「火箭燃料」。如果一個團隊或專案的現狀良好，AI 將能使其表現更上一層樓；但如果現狀本來就有問題，AI 只會加速問題的惡化，讓情況變得更糟。

這個比喻點出了一個重要事實：AI 工具本身並非問題的根源，而是會將團隊現有的工程文化和實踐水準「放大十倍」。許多 AI 工具（例如 Cursor 和 Windsurf）雖然還在持續發展中，但其潛力確實令人興奮。然而，在帶來奇蹟般效率提升的同時，如果使用不當，也可能讓團隊陷入更深的困境。

訓練資料品質決定輸出品質

公開程式碼庫的挑戰

AI 程式碼品質與其訓練資料有著密不可分的關聯。目前大多數 AI 工具的訓練資料主要來自於公開的程式碼庫，但這些資料庫中包含了大量過時、不合時宜，甚至錯誤的程式碼。

一個典型的例子是 Gradle 建構腳本。AI 在生成 Gradle 腳本時表現往往不佳，主要原因是公開的 Gradle 腳本多為實驗性或個人專案，缺乏工業級別的高品質範例。這導致 AI 容易生成不符合最佳實踐的程式碼。

企業級 AI 應用的需求

為了讓 AI 生成高品質的程式碼，企業需要投入更多時間和精力進行以下工作：

  • 客製化 AI 訓練：使用企業內部的高品質程式碼作為訓練資料
  • 建立明確的工程準則：定義清楚的「良好工程實踐」標準
  • 程式碼風格標準化：例如在公司內部統一使用 Checkstyle 等工具

重新定義技術債

避免模糊的術語

Steve Smith 建議我們避免使用「技術債」這個相對模糊的術語，而改用更具體的描述：「難以修改、修改緩慢或修改有風險的程式碼」。這種描述方式更能幫助團隊理解問題的本質，並採取相應的行動。

何時該償還技術債？

Trisha Gee 引用了 Kent Beck 在《Tidy First》一書中的觀點：並非所有的技術債都需要立即償還。如果某段程式碼被視為「黑箱」，未來不太需要修改，那麼即使其內部結構混亂，也可能不會造成實際問題。畢竟，「如果你沒有為此付出代價，那就不算是債務」。

戰略性軟體 vs 實用性軟體

兩位專家以 LMAX 交易平台為例，說明了不同類型程式碼對技術債的容忍度：

業務關鍵 (Business-Critical) 程式碼

  • 例如：高性能的訂單匹配引擎
  • 特點：每一行程式碼都至關重要
  • 處理方式：必須手工精雕細琢，確保效率和穩定性

輔助性 (Utility) 程式碼

  • 例如：交易報告閘道
  • 特點：負責資料轉換和傳輸
  • 處理方式：可以考慮由 AI 生成

這引出了 Martin Fowler 關於「戰略性軟體 (Strategic Software)」與「實用性軟體 (Utility Software)」的劃分：

戰略性軟體：這是公司的核心競爭力所在，應由人類工程師在 AI 輔助下精心打造。

實用性軟體：扮演「黏合劑」的角色，不直接產生核心商業價值，可由 AI 生成或直接購買 SaaS 解決方案。

Steve Smith 建議，在採用 AI 生成服務時，應首先從這些「黏合劑」類型的功能開始，然後再逐步應用到更關鍵的業務領域。

AI 對開發流程的衝擊

大型提交與故障診斷的挑戰

AI 大量生成程式碼可能導致一個嚴重問題：大型、難以追溯的程式碼提交。這與持續交付中提倡的「小批量提交」原則背道而馳，將使問題診斷和回溯變得極其困難。

想像一下，當你面對一個包含數百行 AI 生成程式碼的提交時，要找出其中的問題所在會有多麼困難。這就像是在一堆雜亂的文件中尋找一張重要的發票，效率極低且容易出錯。

故障排除的複雜性

當 AI 生成的程式碼在生產環境中出現問題時，故障診斷將會變得異常複雜：

  • 程式碼理解困難：由於程式碼非人類編寫，可能包含不符合團隊慣例的邏輯
  • 學習成本高：工程師需要在極端壓力下快速理解這些「陌生」程式碼
  • 修復風險：在嘗試修復時可能進一步惡化問題

AI 的「自信」問題

AI 在與人類協作時，有時表現得像一個「極其博學但又過於自信的初級程式設計師」。它缺乏應有的懷疑態度或主動尋求幫助的特質，這可能導致不必要的風險。就像是一個剛畢業的新人，明明不確定答案卻不敢承認，反而可能造成更大的問題。

減輕技術債的實務策略

堅持良好的工程實踐

面對 AI 帶來的挑戰，兩位專家強調了良好軟體工程實踐的重要性：

1. 小型程式碼提交

  • 保持每次提交的變更範圍可控
  • 便於問題追蹤和回溯
  • 降低故障診斷的複雜度

2. 主幹開發 (Trunk-based Development)

  • 減少分支合併的複雜性
  • 提高程式碼整合的頻率
  • 及早發現整合問題

3. 明確的命名標準和設計原則

  • 統一的程式碼風格
  • 清楚的命名規範
  • 一致的架構設計

4. 大量且快速運行的自動化測試

  • 在 AI 大量生成程式碼的環境中，測試尤為重要
  • 這是確保程式碼行為正確的唯一可靠途徑
  • 能夠及早發現 AI 生成程式碼中的問題

AI 增強而非取代

工程師應將 AI 視為結對編程的夥伴，利用其能力來「增強」自身的開發效率，而非完全「取代」人工判斷。這就像是使用計算機來幫助計算，但最終的決策和驗證仍需要人類的智慧。

未來工具的發展方向

預計將出現更多 AI 驅動的分析工具來處理技術債問題：

  • 進階的程式碼分析工具：能夠自動識別程式碼品質問題
  • 可觀察性工具：如 Gradle 的 Develocity 中即將推出的故障分組功能
  • 機器學習輔助診斷：利用 AI 來簡化測試失敗的診斷過程

個人觀點：AI 的雙面性

就像影片中兩位專家所說的，AI 確實可以幫助我們更快速地完成任務，但最終還是需要人類的智慧來進行 review 和決策。

如果原本團隊的工程實踐就還不錯，使用 AI 會加速產品成長，而比較不會有技術債的問題。相反地，如果原本團隊一開始就沒有很好的工程實踐，那 AI 就會帶來更多的技術債。這種負面影響的成長速率可能是沒有 AI 的好幾倍。

這個觀點完美呼應了 Steve Smith 的「火箭燃料」比喻。AI 就像是一個放大器，它會將團隊現有的優缺點都放大。對於已經具備良好工程文化的團隊來說，AI 是一個強大的助手；但對於工程實踐不佳的團隊而言，AI 可能會讓問題雪上加霜。

這也提醒我們，在導入 AI 工具之前，團隊應該先檢視和改善自己的基礎工程實踐。沒有扎實的基礎，再先進的工具也無法發揮真正的價值。

實務建議與行動方案

立即可執行的策略

1. 評估團隊現狀

  • 檢視現有的程式碼品質標準
  • 評估測試覆蓋率和自動化程度
  • 了解團隊的工程文化成熟度

2. 建立防護機制

  • 制定明確的程式碼審查標準
  • 建立自動化的程式碼品質檢查
  • 設定 AI 生成程式碼的使用準則

3. 分階段導入 AI

  • 從非核心的「黏合劑」功能開始
  • 逐步擴展到更重要的業務邏輯
  • 持續監控和調整使用策略

長期發展方向

1. 投資於工程文化

  • 提升團隊對良好工程實踐的認知
  • 建立持續學習和改進的文化
  • 培養批判性思考的能力

2. 建立企業級 AI 應用框架

  • 客製化 AI 訓練資料
  • 建立內部程式碼品質標準
  • 開發專屬的 AI 輔助工具

3. 持續監控和調整

  • 追蹤技術債的變化趨勢
  • 定期評估 AI 工具的效果
  • 調整使用策略和防護措施

結論

AI 確實會製造大量的技術債，這是一個不可否認的現實。但這並不意味著我們應該因噎廢食，完全拒絕使用 AI 工具。關鍵在於如何智慧地應用這些工具，並建立適當的防護機制。

正如 Trisha Gee 和 Steve Smith 所總結的，AI 的導入將把團隊現有的工程文化（無論好壞）「放大十倍」。因此，現在比以往任何時候都更需要專注於提升工程品質、採取更小的交付批次，並明智地將 AI 應用於業務的不同層面。

特別是對於非核心或「膠水」性質的應用程式，AI 有其巨大的價值；但對於業務關鍵的戰略性軟體，人類的監督和精雕細琢仍然不可或缺。

最重要的是，我們需要記住：工具只是工具，真正決定成功與否的，是使用工具的人和團隊的智慧與實踐。在 AI 時代，良好的軟體工程實踐不僅沒有過時，反而變得更加重要。

支持創作

如果這篇文章對您有幫助，歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力！

圖片來源：AI 產生