作為 AutoDev 的核心開發(fā)，我們不僅在不斷豐富 AutoDev 的功能以滿足不同公司的定制需求，還在與各種團(tuán)隊(duì)進(jìn)行持續(xù)交流。在處理遺留系統(tǒng)時(shí)，我們發(fā)現(xiàn)程序員們?nèi)粘９ぷ髦行枰鎸?duì)大量使用過時(shí)技術(shù)、基礎(chǔ)設(shè)施混亂的系統(tǒng)。

在這個(gè)背景下，探索如何利用人工智能增強(qiáng)這些系統(tǒng)的演進(jìn)成為一項(xiàng)極富挑戰(zhàn)性的任務(wù)。畢竟，大佬們都說：所有的應(yīng)用都要重寫一遍。

PS：當(dāng)然了，大佬也在說：未來(lái)不會(huì)有應(yīng)用~~。

為什么場(chǎng)景驅(qū)動(dòng)？

Thoughtworks 與其他大多數(shù)模型廠商不同，一直在探索最佳的編程實(shí)踐。因此，在 AutoDev 中，我們考慮融入各種實(shí)踐，而不僅僅是代碼生成。我們?cè)谠O(shè)計(jì)功能時(shí)一直關(guān)注不同的場(chǎng)景，以滿足不同場(chǎng)景的需求。

在有了大模型加持之后，AI + IDE 有了更多的可能性：

• 代碼增強(qiáng)。即讓 AI 來(lái)加快開發(fā)人員的日常編碼速度，諸如代碼補(bǔ)全、生成文檔、生成測(cè)試等等。

• 普通活動(dòng)增強(qiáng)。即讓 AI 來(lái)修復(fù)錯(cuò)誤、生成提交信息、進(jìn)行代碼檢視等等。

• 融入其他活動(dòng)。即以 IDE 為媒介，持續(xù)將其他的開發(fā)活動(dòng)集成到 IDE 中，諸如文檔查詢、API 接入等等。

而這些都是基于能力所設(shè)計(jì)的，位于其背后其實(shí)包含了一系列的場(chǎng)景：編碼、調(diào)試、測(cè)試、聯(lián)調(diào)等等，每個(gè)場(chǎng)景背后都需要不同的功能來(lái)連動(dòng)，以完成連貫的場(chǎng)景體驗(yàn)。

這就意味著，我們需要能夠更好地：理解和適應(yīng)開發(fā)者在不同場(chǎng)景時(shí)面臨的復(fù)雜情境，并提供更智能、個(gè)性化的開發(fā)體驗(yàn)。諸如于，在遺留系統(tǒng)場(chǎng)景下，它通常具有復(fù)雜的代碼結(jié)構(gòu)和多語(yǔ)言混合使用，往往需要由人來(lái)分析和指令，讓 AI 做一些繁瑣和重復(fù)的工作。

場(chǎng)景：遺留系統(tǒng)改造

對(duì)于編碼和其它場(chǎng)景，在我先前的《上下文工程：基于 Github Copilot 的實(shí)時(shí)能力分析與思考》 等文檔，以及 NJSD 大會(huì)的《從個(gè)人到組織， AIGC技術(shù)的工程化落地》上的分享里，已經(jīng)做了詳細(xì)的介紹。而作為一個(gè)開發(fā)團(tuán)隊(duì)，我們每天不可能有大量的新增代碼，大部分人還是工作在遺留系統(tǒng)上 —— 一個(gè)你可能不知道某個(gè)功能、某塊業(yè)務(wù)是如何實(shí)現(xiàn)的？

生成式 AI 增強(qiáng) ：“遺留系統(tǒng)改造”

在我開源的那本《系統(tǒng)重構(gòu)與遷移指南》（https://github.com/phodal/migration，stars：3.3k）電子里，詳細(xì)介紹了如何分析、評(píng)估現(xiàn)有系統(tǒng)、制定重構(gòu)策略、探索可行重構(gòu)方案等一系列的遺留系統(tǒng)重寫與重構(gòu)模式。

基于經(jīng)典的遺留系統(tǒng)重構(gòu)范式，在代碼層面我們要做這么一些事情：

• 建立評(píng)估與度量

• 搭建測(cè)試防護(hù)網(wǎng)

• 重新設(shè)計(jì)系統(tǒng)架構(gòu)。諸如于 DDD 用于改善模塊化架構(gòu)

• 業(yè)務(wù)提取與服務(wù)重構(gòu)。

• 進(jìn)行細(xì)粒度的重構(gòu)。諸如于代碼等等

而在有了生成式 AI 之后，在我們做完了頂層設(shè)計(jì)之后，它可以大大加速我們的落地實(shí)踐。

創(chuàng)意階段：增強(qiáng)環(huán)節(jié)分析

基于這個(gè)場(chǎng)景之下，我們就需要思考哪些功能可以借助生成式 AI 來(lái)輔助。如下我們是會(huì)在頭腦風(fēng)暴時(shí)產(chǎn)生的一些想法：

• 改造方案設(shè)計(jì)。即通過聊天的方式，獲得一些創(chuàng)意式的輸入，以幫助我們更好地編寫解決方案。

• 測(cè)試防護(hù)網(wǎng)搭建。根據(jù)系統(tǒng)的復(fù)雜度，需要?jiǎng)?chuàng)建不同維度的測(cè)試數(shù)據(jù)、測(cè)試用例等。

• 系統(tǒng)架構(gòu)設(shè)計(jì)。即通過聊天的方式，獲得一些創(chuàng)意式的輸入，以知道什么是更好的架構(gòu)。

• 業(yè)務(wù)信息提取。即通過文檔生成、調(diào)用鏈分析等方式，分析某一個(gè) API 的業(yè)務(wù)與實(shí)現(xiàn)邏輯。

• 基礎(chǔ)設(shè)施重寫。諸如 Maven 遷移到 Gradle，上云基礎(chǔ)設(shè)施改造（Dockerfile 生成 等）。

• 代碼重寫。適用于語(yǔ)言翻譯（如 js 轉(zhuǎn)換 ts）、邏輯優(yōu)化等場(chǎng)景。

• 文檔重新生成。即針對(duì)于現(xiàn)有的舊文檔，重新生成一份新的文檔。

• ……

除了，這些通用的功能之后，事實(shí)上還存在大量的復(fù)雜場(chǎng)景，諸如于：

• 存儲(chǔ)過程代碼的分析與遷移。

• 復(fù)雜構(gòu)建腳本的遷移。

• 領(lǐng)域特定語(yǔ)言的重寫。

根據(jù)不同的場(chǎng)景，我們都需要有選擇地進(jìn)行設(shè)計(jì)和強(qiáng)化。但是，顯然我們可以看到生成式 AI 可以大大加速這一過程。

端到端定制方案

而對(duì)于更復(fù)雜的場(chǎng)景而言，我們則需要構(gòu)建專有的工具來(lái)實(shí)現(xiàn)這個(gè)過程。諸如于 IBM 在設(shè)計(jì)針對(duì)于 COBOL 語(yǔ)言遷移時(shí)，將重構(gòu)過程分為了三大階段：

• 理解。即理解 COBOL 代碼中的代碼、數(shù)據(jù)、依賴部分，采用諸如可視化等方式設(shè)計(jì)。

• 重構(gòu)。將已有的 COBOL 代碼解耦，并重構(gòu)為模塊化的方式。

• 轉(zhuǎn)換。將模塊化的代碼翻譯為 Java 代碼。

而過程中，還需要針對(duì)于已有的業(yè)務(wù)編寫對(duì)應(yīng)的 Java 測(cè)試代碼，以方便進(jìn)行手動(dòng)和自動(dòng)化的驗(yàn)證。

AI 如何增強(qiáng)遺留系統(tǒng)改造？

在對(duì)遺留系統(tǒng)進(jìn)行改造時(shí)，智能 IDE 的升級(jí)將是一個(gè)關(guān)鍵因素。然而，如何將新功能轉(zhuǎn)化為易于操作和高效的組件，以及如何在不同場(chǎng)景中提供最佳的用戶體驗(yàn)，是一項(xiàng)具有挑戰(zhàn)性的任務(wù)。

在功能與場(chǎng)景的設(shè)計(jì)中，我們需要回答一些關(guān)鍵問題：

1. 何時(shí)開發(fā)新功能？ 確定新功能的開發(fā)時(shí)機(jī)，使其與遺留系統(tǒng)的改造需求相匹配。

2. 何時(shí)開放定制化能力？ 確定定制化的靈活性在哪些場(chǎng)景下是必要的，以滿足用戶的個(gè)性化需求。

3. 何時(shí)交由開發(fā)人員決定？ 確定哪些場(chǎng)景下，完全交由開發(fā)人員決定，以保持系統(tǒng)的靈活性。

并且，我們還應(yīng)該確保這些功能應(yīng)該是方便使用的。當(dāng)然了，最簡(jiǎn)單的方式就是完全開放這種定制能力?；谶@些思考，以我們開源 AutoDev 插件為例來(lái)介紹。

如何驗(yàn)證生成的代碼？

在引入 AIGC 來(lái)生成代碼時(shí)，都需要考慮的一個(gè)點(diǎn)是：如何驗(yàn)證生成代碼的準(zhǔn)確性？。這是一個(gè)復(fù)雜的問題，通常來(lái)說，應(yīng)該是再由人去驗(yàn)證一遍的，但是有各種取巧的方式。諸如：

1. 結(jié)合人工智能進(jìn)行檢查： 利用人工智能輔助驗(yàn)證生成的代碼，提高驗(yàn)證效率。

2. 生成測(cè)試以驗(yàn)證業(yè)務(wù)代碼： 通過生成測(cè)試用例，確保生成的代碼在業(yè)務(wù)場(chǎng)景中的正確性。

3. 基于測(cè)試用例文檔生成單元測(cè)試： 利用測(cè)試用例文檔生成單元測(cè)試，使驗(yàn)證過程更加規(guī)范化。

當(dāng)然了，這些都是規(guī)范化的團(tuán)隊(duì)所做的事情，實(shí)在不行就如我們?cè)?Unit Mesh 架構(gòu)所說的，由人來(lái)驗(yàn)證 AI 生成的代碼。而在進(jìn)行遺留系統(tǒng)改造時(shí)，有時(shí)這個(gè)問題就顯得比較簡(jiǎn)單了 —— 只需要驗(yàn)證輸入和輸出，諸如于 Http API 的輸入和輸出。

所以，對(duì)應(yīng)到功能上，只需要一鍵生成測(cè)試或者生成測(cè)試的方式，也就可以分為專有和自定義能力。

完成自定義：自定義語(yǔ)言轉(zhuǎn)換

自定義是三種模式里最懶的方案，然而也是在實(shí)現(xiàn)上最復(fù)雜的，采用何種的交互方式，如何提供這一類靈活的接口。

作為工具的設(shè)計(jì)者，其實(shí)我們是無(wú)法枚舉語(yǔ)言間的轉(zhuǎn)換，常用的語(yǔ)言都有十幾個(gè)，他們之間可以隨意轉(zhuǎn)換。這也就是最開始的是一個(gè)自定義 Action（https://ide.unitmesh.cc/custom/action），讓開發(fā)人員可以通過 JSON 來(lái)配置這種轉(zhuǎn)換：

{
"title": " Translate to Kotlin",
"autoInvoke": false,
"matchRegex": ".*",
"priority": 0,
"template": "將如下的代碼翻譯為 Kotlin.\n${SIMILAR_CHUNK}\nCompare these snippets:\n${METHOD_INPUT_OUTPUT}\n原始代碼如下:\n${SELECTION}"
}

并將相似的代碼塊 ${SIMILAR_CHUNK} 和函數(shù)的輸入和輸出 {METHOD_INPUT_OUTPUT} 作為上下文的一部分。

部分定制：活文檔生成

開放定制是三種模式最復(fù)雜的，如何去平衡應(yīng)該由程序的某一部分來(lái)完成，這并不是一件容易的事情。并且也有可能，它會(huì)變成一種不三不四的方案。

對(duì)于復(fù)雜的遺留系統(tǒng)來(lái)說，我們還需要理解現(xiàn)有的業(yè)務(wù)，需要了解業(yè)務(wù)的各種信息。而我們所推薦的一種方式就是活文檔。活文檔的方式有多種多樣的，在代碼中一種比較簡(jiǎn)單的實(shí)現(xiàn)方式就是通過注解。

而由于注釋本身就是文檔，所以活文檔的功能在實(shí)現(xiàn)時(shí)是與注釋生成一起的，其自定義方式如下：

{
"title": "Living Documentation",
"prompt": "編寫 Living Documentation。按如下的格式返回：",
"start": "",
"end": "",
"type": "annotated",
"example": {
"question": "public BookMeetingRoomResponse bookMeetingRoom(@RequestBody BookMeetingRoomRequest request) {\n MeetingRoom meetingRoom = meetingRoomService.bookMeetingRoom(request.getMeetingRoomId());\n BookMeetingRoomResponse response = new BookMeetingRoomResponse();\n BeanUtils.copyProperties(meetingRoom, response);\n return response;\n }",
"answer": " @ScenarioDescription(\n given = \"there is a meeting room available with ID 123\""