怎样看一个网站是不是织梦做的,北京市建设工程质量监督网站,比较好的网站公司,wordpress图片上添加图标作为 AutoDev 的核心开发#xff0c;我们不仅在不断丰富 AutoDev 的功能以满足不同公司的定制需求#xff0c;还在与各种团队进行持续交流。在处理遗留系统时#xff0c;我们发现程序员们日常工作中需要面对大量使用过时技术、基础设施混乱的系统。 在这个背景下#xff0c… 作为 AutoDev 的核心开发我们不仅在不断丰富 AutoDev 的功能以满足不同公司的定制需求还在与各种团队进行持续交流。在处理遗留系统时我们发现程序员们日常工作中需要面对大量使用过时技术、基础设施混乱的系统。 在这个背景下探索如何利用人工智能增强这些系统的演进成为一项极富挑战性的任务。毕竟大佬们都说所有的应用都要重写一遍。 PS当然了大佬也在说未来不会有应用~~。 为什么场景驱动 Thoughtworks 与其他大多数模型厂商不同一直在探索最佳的编程实践。因此在 AutoDev 中我们考虑融入各种实践而不仅仅是代码生成。我们在设计功能时一直关注不同的场景以满足不同场景的需求。 在有了大模型加持之后AI IDE 有了更多的可能性 代码增强。即让 AI 来加快开发人员的日常编码速度诸如代码补全、生成文档、生成测试等等。普通活动增强。即让 AI 来修复错误、生成提交信息、进行代码检视等等。融入其他活动。即以 IDE 为媒介持续将其他的开发活动集成到 IDE 中诸如文档查询、API 接入等等。 而这些都是基于能力所设计的位于其背后其实包含了一系列的场景编码、调试、测试、联调等等每个场景背后都需要不同的功能来连动以完成连贯的场景体验。 这就意味着我们需要能够更好地理解和适应开发者在不同场景时面临的复杂情境并提供更智能、个性化的开发体验。诸如于在遗留系统场景下它通常具有复杂的代码结构和多语言混合使用往往需要由人来分析和指令让 AI 做一些繁琐和重复的工作。 场景遗留系统改造 对于编码和其它场景在我先前的《上下文工程基于 Github Copilot 的实时能力分析与思考》 等文档以及 NJSD 大会的《从个人到组织 AIGC技术的工程化落地》上的分享里已经做了详细的介绍。而作为一个开发团队我们每天不可能有大量的新增代码大部分人还是工作在遗留系统上 —— 一个你可能不知道某个功能、某块业务是如何实现的 生成式 AI 增强 “遗留系统改造” 在我开源的那本《系统重构与迁移指南》https://github.com/phodal/migrationstars3.3k电子里详细介绍了如何分析、评估现有系统、制定重构策略、探索可行重构方案等一系列的遗留系统重写与重构模式。 基于经典的遗留系统重构范式在代码层面我们要做这么一些事情 建立评估与度量搭建测试防护网重新设计系统架构。诸如于 DDD 用于改善模块化架构业务提取与服务重构。进行细粒度的重构。诸如于代码等等 而在有了生成式 AI 之后在我们做完了顶层设计之后它可以大大加速我们的落地实践。 创意阶段增强环节分析 基于这个场景之下我们就需要思考哪些功能可以借助生成式 AI 来辅助。如下我们是会在头脑风暴时产生的一些想法 改造方案设计。即通过聊天的方式获得一些创意式的输入以帮助我们更好地编写解决方案。测试防护网搭建。根据系统的复杂度需要创建不同维度的测试数据、测试用例等。系统架构设计。即通过聊天的方式获得一些创意式的输入以知道什么是更好的架构。业务信息提取。即通过文档生成、调用链分析等方式分析某一个 API 的业务与实现逻辑。基础设施重写。诸如 Maven 迁移到 Gradle上云基础设施改造Dockerfile 生成 等。代码重写。适用于语言翻译如 js 转换 ts、逻辑优化等场景。文档重新生成。即针对于现有的旧文档重新生成一份新的文档。…… 除了这些通用的功能之后事实上还存在大量的复杂场景诸如于 存储过程代码的分析与迁移。复杂构建脚本的迁移。领域特定语言的重写。 根据不同的场景我们都需要有选择地进行设计和强化。但是显然我们可以看到生成式 AI 可以大大加速这一过程。 端到端定制方案 而对于更复杂的场景而言我们则需要构建专有的工具来实现这个过程。诸如于 IBM 在设计针对于 COBOL 语言迁移时将重构过程分为了三大阶段 理解。即理解 COBOL 代码中的代码、数据、依赖部分采用诸如可视化等方式设计。重构。将已有的 COBOL 代码解耦并重构为模块化的方式。转换。将模块化的代码翻译为 Java 代码。 而过程中还需要针对于已有的业务编写对应的 Java 测试代码以方便进行手动和自动化的验证。 AI 如何增强遗留系统改造 在对遗留系统进行改造时智能 IDE 的升级将是一个关键因素。然而如何将新功能转化为易于操作和高效的组件以及如何在不同场景中提供最佳的用户体验是一项具有挑战性的任务。 在功能与场景的设计中我们需要回答一些关键问题 何时开发新功能 确定新功能的开发时机使其与遗留系统的改造需求相匹配。何时开放定制化能力 确定定制化的灵活性在哪些场景下是必要的以满足用户的个性化需求。何时交由开发人员决定 确定哪些场景下完全交由开发人员决定以保持系统的灵活性。 并且我们还应该确保这些功能应该是方便使用的。当然了最简单的方式就是完全开放这种定制能力。基于这些思考以我们开源 AutoDev 插件为例来介绍。 如何验证生成的代码 在引入 AIGC 来生成代码时都需要考虑的一个点是如何验证生成代码的准确性。这是一个复杂的问题通常来说应该是再由人去验证一遍的但是有各种取巧的方式。诸如 结合人工智能进行检查 利用人工智能辅助验证生成的代码提高验证效率。生成测试以验证业务代码 通过生成测试用例确保生成的代码在业务场景中的正确性。基于测试用例文档生成单元测试 利用测试用例文档生成单元测试使验证过程更加规范化。 当然了这些都是规范化的团队所做的事情实在不行就如我们在 Unit Mesh 架构所说的由人来验证 AI 生成的代码。而在进行遗留系统改造时有时这个问题就显得比较简单了 —— 只需要验证输入和输出诸如于 Http API 的输入和输出。 所以对应到功能上只需要一键生成测试或者生成测试的方式也就可以分为专有和自定义能力。 完成自定义自定义语言转换 自定义是三种模式里最懒的方案然而也是在实现上最复杂的采用何种的交互方式如何提供这一类灵活的接口。 作为工具的设计者其实我们是无法枚举语言间的转换常用的语言都有十几个他们之间可以随意转换。这也就是最开始的是一个自定义 Actionhttps://ide.unitmesh.cc/custom/action让开发人员可以通过 JSON 来配置这种转换 {
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} 和函数的输入和输出 {METHOD_INPUT_OUTPUT} 作为上下文的一部分。 部分定制活文档生成 开放定制是三种模式最复杂的如何去平衡应该由程序的某一部分来完成这并不是一件容易的事情。并且也有可能它会变成一种不三不四的方案。 对于复杂的遗留系统来说我们还需要理解现有的业务需要了解业务的各种信息。而我们所推荐的一种方式就是活文档。活文档的方式有多种多样的在代码中一种比较简单的实现方式就是通过注解。 而由于注释本身就是文档所以活文档的功能在实现时是与注释生成一起的其自定义方式如下 {
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\,\n when \a user books the meeting room with ID 123\,\n then \the booking response should contain the details of the booked meeting room\\n )
}
} 这里的 example 是为 LLM 提供一个示例以更符合生成的结果。从实现上远比先前的完成自定义复杂得多。 专有的新特性API 测试数据生成 专有特性是三种模式中最简单的也是最不对用户负责的。我们直接将功能放入到了系统中用户的系统菜单和交互变得异常臃肿。 在实现上也只需要根据这些场景做一些简单的接口和实现即可。 总结 开发一个 AI 原生应用并不是一件简单的事。我们应该思考如何将生成式 AI 应用对更有价值的日常活动中我们应该思考如何将更多的自主性和决定权交由用户 如果你也有兴趣来探索欢迎来 AutoDev 探索https://github.com/unit-mesh/auto-dev 。 AutoDev 功能全景 Unit Mesh 开源项目全景https://github.com/unit-mesh/
