# 我們在 2 週內完成了 Enzyme 遷移。這本應需要五年的時間

> 我們最近使用 AI 在大約一次衝刺中完成了多年的工程工作，以便從 Enzyme 進行遷移。以下是 Asana 團隊達成此目標的方式。

Source: https://asana.com/zh-tw/inside-asana/migrating-off-enzyme-2-weeks

## 我們在 2 週內完成了 Enzyme 遷移。這本應花費五年的時間。

我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。

## 五年問題

早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓勵進行與實作詳細資料緊密耦合的測試，而不是與使用者實際看到和執行的操作緊密耦合的測試。 RTL 促使我們採用更好的模型：測試行為，而非內部運作。

多年來，移轉工作取得穩定進展。 為此，我們配置了幾個需要多位工程師參與、為期一年的專案。 產品團隊逐步完成了他們負責的部分。 所有這些工作都很重要。 但按照我們的進度，我們距離完成還有大約**五年的時間**。

因此，我們有意設定了一個不合理的目標：如果我們在一週內完成整個遷移，會怎麼樣？

我們差不多做到了。 工程時間大約花了一週半。 Enzyme 現在已完全從程式碼庫中消失。

## 實際過程

這個方法簡單到幾乎令人尷尬。 我們使用 OpenAI 的 Codex，搭配超高推理能力的前沿模型，一次最多運行四個代理程式，每個代理程式指向不同的目錄。 我們讓機器保持運作，讓代理程式日夜運行，並且每天早上和晚上都會查看，以審查進度並開啟提取請求。

以下是完整的提示：

**/目標**我們希望將儲存庫從 Enzyme 測試遷移至 React Testing Library 形式的測試。 依循程式碼庫中現有的規範和最佳作法。 將 中使用 enzyme 的所有檔案遷移為使用 react testing library。 使用 [_**test command]**_測試您的變更。 一般傾向先移轉易於轉換的檔案。

五個句子。 就這樣。

我們也嘗試過更複雜的設定：將工作分解成可追蹤的工單，讓代理程式保留一個持續更新的備註檔案，要求它產生子代理程式以進一步平行處理，以及撰寫更詳細的 RTL 規範提示。 幾乎所有這些做法都讓情況變得更糟。 簡單的方法贏了。

## 為什麼五句提示就足夠

這是最重要的部分，也是 OpenAI 最近在[Harness engineering](https://openai.com/index/harness-engineering/)中所寫的相同想法：代理程式輸出的品質在很大程度上取決於您提供的環境品質。

我們的程式碼庫已經融入了多年的良好品味：最初採用 RTL 的決定、精心設計的測試輔助工具、清晰的慣例，以及可供參考的真實範例。 模型不需要我們解釋任何內容；這些內容已經存在，可供閱讀。 我們只是提供目標，並讓代理程式執行。

任務本身也具有正確的形式，使其能夠發揮作用：完整且可驗證的完成定義（不再使用 Enzyme），以及快速的回饋迴圈（型別檢查、linting、測試、CI），這些都能立即發現錯誤。 良好的控制環境、定義明確的問題，只需最少的引導。

## 阻礙因素

大部分的阻礙並非模型的錯，而是我們的錯：
- 一些最近撰寫的內部文件和代理程式指南仍將 Enzyme 視為首選模式，主動將代理程式引導至錯誤的方向。 過時的文件不再只是一個小小的麻煩；對於每一位閱讀它的專員來說，這是誤導性的培訓材料。
- 我們發現，最需要介入的地方是緩慢且不穩定的工具 (Lint 步驟有時需要十多分鐘，CI 和本機檢查之間不相符)。 服務專員很少是瓶頸，我們自己的基礎架構才是。

## 現在，Harness 就是產品

從此專案中學到的一個更明確的經驗教訓是：AI 不會消除對工程品味的需求，反而會放大這種需求。 程式碼庫中乾淨的範例和清晰的約定產生了乾淨、完善的輸出。 尷尬的模式也被複製了。 我們的文件也是如此，過時的指南變成了一個負擔，而當只有人類閱讀時，情況從未如此。

令人鼓舞的另一面是，這也會朝另一個方向發展。 良好的範例會傳播。 清晰的文件可正確引導代理程式。 投資於「支援」 (即與程式碼相關的文件、慣例和回饋循環) 將在未來的每次遷移中都能獲得回報，而不僅僅是這一次。

### 接下來

我們對此對 Asana 的意義充滿信心，也知道這可能會令人感到不安，因為工程師的身分很大程度上與手寫程式碼息息相關。 我希望這能讓我們有更多時間關注技藝，而不是更少，並且對長期進行的遷移、重寫和績效問題這些待辦項目抱持更大的野心，我們一直默默以為這些問題總是需要數年的時間。

並非所有這些問題都會從數年縮短至一週。 但有些問題會。 值得提出的問題不僅僅是「我們在這裡使用 AI 嗎？」 而是「我們是否真的嘗試過在週末讓代理程式處理這件事，然後在週一查看結果？」

#### **對於有興趣的人，以下是一些額外的詳細資料：**
- 整個遷移大約花費一週半的工程時間，分散在兩個行事曆週內。
- 模型使用成本約為 11,000 美元，基礎架構成本為 1,000 美元
- 為了讓大家更容易理解這 12,000 美元的成本 (簡單計算)：這項工作最終帶來的好處超出了原始架構遷移本身。 在此過程中，我們還改善了測試涵蓋範圍、修復了不良測試，並清理了舊版測試基礎架構。 我們估計，若要手動完成整個範圍，工程投入量將達到大約 600 萬美元。
- 我們在此過程中發現了一些意外的成果，包括清理一個更舊的 Enzyme 之前的測試架構，我們已經忘記它仍然存在於程式碼庫的某些部分。

_本文是 Asana 和 OpenAI 之間持續合作與夥伴關係的一部分，旨在探索 Codex 如何承擔更大型、更具挑戰性的工程工作。_

- [我們在 2 週內完成了 Enzyme 遷移。這本應需要五年的時間](/zh-tw/inside-asana/migrating-off-enzyme-2-weeks)

工程

我們最近使用 AI，在大約一次衝刺中完成了多年的工程工作。 以下是其方法，以及為什麼它改變了我們對可能性的看法。五年問題早在 2022 年，我們就著手將 Asana 的前端測試套件從我們老舊的測試庫 Enzyme 移轉至 React Testing Library (RTL)。 Enzyme 已經失去社群支援，無法與較新版本的 React 正常搭配，並且鼓 ...

- [工程](/inside-asana/engineering-spotlight)