去年 8 月,在看到 IBM 在自家的 watsonx Code Assistant 中加入了 COBOL 语言转 Java 的功能后。在分析了一下午之后,我似乎理解了它的工作思想,以及应该如何去设计这样的 AI 辅助工具。而考虑到 AutoDev 并非专门为遗留系统改造而设计的,所以只能将相同的功能以不同的方式结合到一起。
随着,我们在辅助测试和 SQL 的完善,在 AutoDev 中具备了基础的辅助遗留系统改造功能:
详细可以参见 AutoDev 场景文档系列:https://ide.unitmesh.cc/scenes/legacy-migration.html 。
在过去的几年里,Thoughtworks 在行业内分享了一系列遗留系统改造的经验,绞杀者模式 vs 修缮模式、N 步重构法等。作为一个写过几个重构工具的砖家,我也在五年前编写了《系统重构与迁移指南》(https://migration.ink/)。
从模式上来说,遗留系统重构的过程可以简单分为:
根据不同的系统在实现上略有差异,回到 IBM 的 COBOL 迁移工具的设计中,几乎以上述的过程是相似的:
但是,在不同的场景上会出现一些差异,这也是我们在设计工具时所需要考虑的。
结合我们丰富的遗留系统重构经验,我们还是可以按上述的几个步骤来构建 AI 工具。
遗留系统的一大痛点是没有知道业务知识,所以在生成式 AI 的加持下,问题域可以变为:
如结合我们以往的工具,我们在 AutoDev 的文档生成功能中添加了活文档(Living Documentation)的功能,你可以结合注解从现有的逻辑中可视化业务。
如下是一个结合 AutoDev 生成活文档的示例:
@ScenarioDescription(
given = "a file with name $filename and program text $programText",
when =
"the function tryFitAllFile is called with maxTokenCount $maxTokenCount, language $language, and virtualFile $virtualFile",
then = "the function should return an ErrorScope object with the correct values"
)
随后,就可以清晰地呈现已有的逻辑实现。
通常来说,为了代码修复后功能是正常的,需要针对于 API 级别进行功能测试。所以,我们需要结合 API 测试工具或者是最外层的 Controller 进行测试。
有了足够的测试防护网之后,我们就可以开始进行对应的代码转换。
尽管 AI 翻译跨语言的代码时,并不是那么准确,可能出现一些 API 错误。诸如于,在 PL/SQL 中的函数写法不一致,导致在翻译成 Java 时会出现函数不存在。因此,我们需要一次性的将一段存储过程的代码翻译完,以确保翻译是通过的。
对应的,这个功能在 AutoDev 上的实现便是自定义 Prompts,以支持更丰富的翻译功能。
由于不同语言间存在一些能力等的差异,所以我们需要考虑到不同的语言的场景。诸如于,在 AutoDev 中针对于 PL/SQL 构建了相似的功能:
考虑到对于语言的理解,能力还是有待进一步完善的。
总而言之,言而总之,遗留系统还是一个颇为理想的 AI 辅助场景。AI 可以增强我们现有的重构方式,但是是否存在新的方式是一个特别有意思的问题。
围观我的Github Idea墙, 也许,你会遇到心仪的项目