ExplainThis 全端開發雙週報 #51
如何有效推動大規模技術遷移
嗨～ 歡迎閱讀第 51 期的 ExplainThis 全端雙週報。
在進到這期的主題文之前，想分享 ExplainThis 在上週正式上架了《給工程師的 Cursor 工作流 — 透過 AI 代理全方位提升開發生產力》線上課程，希望透過這門課與讀者們分享如何透過 AI 代理，在工程師的工作各面向上，提高生產力與效率。
雖然這門課是以 Cursor 做為主要工具，但課程中講到的概念，都適用其他 AI 驅動的工具 (例如 Windsurf 或 GitHub Copilot)。感興趣的讀者，可以加入 E+ 成長計畫 (連結)。
以上，讓我們進到這期的雙週報主題文吧～
如何有效推動大規模技術遷移
前陣子有讀者來信問到「目前在公司負責開發的專案因為初始建置時沒有選用 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 工具來加速大規模技術遷移，也是很有效的方式之一。
舉例來說，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+ 成長計畫的主題文都有談到，有興趣的讀者歡迎加入閱讀（連結)。
本期推薦
前 OpenAI 研究員 Daniel Kokotajlo 的團隊發表了 AI 2027，預測接下來各領域的 AI 發展，網站做得非常精美，也回答了許多人關心的問題 (連結)。
談到 AI 發展，在 OpenAI 之後，Google 這週也宣布支援 MCP (連結)，同時發表 A2A 這個讓代理互動的協定 (連結)。對 MCP 不熟的讀者可以參考先前我們寫的介紹，以及在使用 MCP 時要小心被攻擊的問題 (連結)
Node.js 的核心維護者 Matteo Collina 分享了自己新寫的《The Definitive Guide for Node.js in Enterprise》一書，在談開發 Node.js 企業級應用時的各種眉角。這本書的電子版本可以免費下載，非常佛心 (連結)。我們有將更多給前後端工程師的資源彙整在 PinThis 資源站，可以看這邊 (連結)
先前 ExplainThis 曾寫過設計即時共編的技術內容 (連結)，在這類系統設計題目，很常會追問如何設計「回到上一步的功能」。最近讀到 《A Tiny Undo Stack》 一文正好在談這個實作 (連結)
前 Google 工程師 Jacob Voytko 分享了《War story: the hardest bug I ever debugged》一文，談了他在工程師生涯中遇過最困難的 bug，以及解決該問題的過程，在當中去追問題根源所做的，很值得效法 (連結)
Rachel-Lee Nabors 上週給了《The Death of Browser》的分享，雖然標題有點聳動，但實際上是從技術歷史發展的角度，來看瀏覽器的演變，是相當有洞見的演講，推薦一看 (連結)
最近看到 Typed Japanese 這個開源專案，用 TypeScript 的角度切入拆解日語。假如是已經會靜態型別程式語言的人，要入門日語文法變得很簡單，是非常酷的專案 (連結)
文末彩蛋
上週讀到 Jack Altman 提到的一個觀點，是他擔心在下個世代中「用 AI 學習」與「用 AI 來跳過學習」這兩個族群，在能力上的差距會越來越大。
雖然 ExplainThis 團隊自己有推出使用 AI 工具來提高生產力的課程，但是在課程中我們不斷強調，雖然 AI 能夠代勞許多事情，但是在使用的過程中，絕對不能失去了自己的獨立思考與判斷。
有些人用了 AI 後，僅求讓 AI 完成任務，因而在過程中不再思考，這樣長期下來反而可能弊多於利。比較健康且長久的的做法，是用 AI 來加速完成任務，同時在過程中透過 AI 來放大學習。
願讀者們在 AI 時代下，都能成為更有思考、學習能力的人，而不僅是一隻隨機鸚鵡。
I'm slightly worried that the next generation of kids graduating are going to a wider gulf than ever between the people who used AI to learn everything and the people who used AI to skip learning anything.
— Jack Altman