如何有效推動大規模技術遷移?

前陣子有讀者來信問到「目前在公司負責開發的專案因為初始建置時沒有選用 TypeScript，因此一直使用 JavaScript 至今，因為目前各個趨勢都顯示 TypeScript 的重要性，而自己對 TypeScript 十分初學、需要實際應用經驗，想請問在這種情況下，有建議辦法讓我有機會在公司用 TypeScript 嗎？」

針對讀者的這個問題，一個有效的解法是讓公司知道「遷移的成本沒有預期中的高」。藉此讓公司或團隊願意投入去遷移。

然而，要如何做到呢?

事前調查可用的工具

事前調查可用的工具，會是一個有效的關鍵。在進行程式碼庫遷移時，如果只是手動的一行行重新用新的技術寫，那會是最耗時間成本的。要能夠用最有效率的方式進行遷移，務必要善用相關的工具。因此，推薦在實際執行遷移前，先調查有哪先可以用的工具，讓遷移能用效率更好的方式完成。

舉例來說，在《Migrating millions of lines of code to TypeScript》一文當中，Stripe 團隊分享了從 Flow 遷移到 TypeScript 的經驗，並提到透過 Codemod 工具 (連結)，做語法上面的轉換。因為許多語法是固定的，所以透過寫 Codemod 的腳本，可以用程式的方式來做大範圍的遷移。

事實上，在更早之前 Airbnb 團隊有開源 ts-migrate (連結)，這個工具可以直接把整個 JavaScript 遷移成 TypeScript。當然一開始會有很多 any ，但這可以一步步慢慢修，只是最起碼確保專案在遷移後，新的程式碼都是用 TypeScript 來寫。

用這種方式，就可以讓初期的遷移成本幾乎為零 (雖然有一點小代價是會有很多 any 在程式碼庫中)，但是這樣做讓接下來都能改用 TypeScript 寫，成果面來看很值得。

透過 AI 加速

除了傳統的軟體工具外，在 AI 時代，透過 AI 工具來加速大規模技術遷移，也是很有效的方式之一。

舉例來說，Google 在 2025 年發表的《How is Google using AI for internal code migrations? 》談到在 Google 內部用 LLM 協助進行程式碼遷移。而 Amazon 在《Evaluating Human-AI Partnership for LLM-based Code Migration》也談到內部用 LLM 遷移上百萬行 Java 程式碼，從 Java 8 升級到 Java 17。此外，前面有提到的 Airbnb，在近期進行大規模的測試程式碼遷移時，也透過 LLM 大幅加速 (連結)。

之所以 LLM 在程式碼遷移有幫助，是因為許多傳統的軟體工具，在遷移時的幫助有限。因為傳統軟體能做的，是去寫某些規則，但因為程式碼很常會是有多種變異的，所以用固定的規則，在某些清況下會不足以應付。而 LLM 在這種有變異性的狀況下，發揮會比較好。

首先我們看到 Google 的做法，LLM 在過程中有幾個作用，首先是找尋要被遷移的程式碼，在找到後會寫一個新的版本，接著會跑測試，假如測試沒過 LLM 會迭代下一輪繼續修改直到測試通過。而最後程式碼會由工程師來做 code review。透過這樣的流程，上百萬行程式碼的遷移時間，省下超過 50%。

在《How is Google using AI for internal code migrations? 》這篇發表中，有談到幾個過程中運用上的方法，分別包含

在遷移過程不僅用 LLM，而是搭配 AST 工具來確保正確性，同時降低成本。之所以能降低成本，是因為很多固定的東西，可以由 AST 相關工具處理，所需的運算資源遠低於 LLM，在百萬行程式碼的遷移下，累加能省的成本不少
為 LLM 設計工具包 (toolkit)，包含測試檔案(test files)、接口檔案 (interface files)、相關依賴的資訊，透過這個方式，模型會有比較充足的脈絡來進行遷移
分治法 (divide and conquer)，如同許多演算法會把東西先拆小然後分別擊破，在用 AI 協助遷移時，這個方法也很有幫助。一次要 AI 處理百萬行程式碼，在現行技術仍做不到，但是如果把問題拆小，然後把一個個小部分完成遷移，這樣累加起來也能完成大規模遷移

閱讀更多

事實上，有做好大規模技術遷移，還有很多細節要照顧，包含事前的評估、準備事項，以及遷移時要有方法來確保穩定性，要透過 AI 加速時需要在提示詞下足功夫。這些點我們在 E+ 成長計畫的主題文都有談到，有興趣的讀者歡迎加入閱讀（連結)。