利用AI工具，超越代码实现软件架构

本文将探讨如何运用AI辅助实现软件架构现代化，结合具体示例展示AI如何协助达成这一目标，包括提供一致且正确的架构建议、帮助软件团队逐步从遗留系统的泥潭中抽身出来。

凭借GitHub Copilt、Amazon Q等AI驱动编程工具的助力，如今企业团队的代码交付量与交付频率均创下历史新高。

但这也带来了新的问题。

AI协助团队产出更多代码的同时，原有遗留系统以及长期累积下的技术债也日益恶化。架构的现代化转型需求，就成了必须直面的关键挑战。

换言之，仍有大量开发者需要将时间耗费在维护过时代码、旧框架和累积架构上，导致遗留系统的运维成本越来越高。

更糟糕的是，AI工具几乎完全不了解遗留软件架构，因此在尝试对接的过程中，不仅没有改善旧有体系、反而令形势每况愈下。

本文将探讨如何运用AI辅助实现软件架构现代化，结合具体示例展示AI如何协助达成这一目标，包括提供一致且正确的架构建议、帮助软件团队逐步从遗留系统的泥潭中抽身出来。

AI与软件架构之问

AI极其高效的代码产出能力已经得到全球开发者的肯定，可问题在于，对AI的持续使用也会对架构产生影响。

开发者在编码时，会持续思考并解决以下问题：

• 如何组织类？
• 如何处理缓存？
• 将业务逻辑放在哪里？
• 存在哪些外部依赖项？
• 业务逻辑应如何融入整体软件架构？
• 诸如此类……

AI智能体其实也会思考这些问题，并在生成的每行代码中悄悄做出架构决策。

而其中的风险，在于这些聪明且不知疲倦的编程助手经常做出局部最优选择——即在当前场景下看似正确，但却给整体软件架构增加了更多负担。

更可怕的是，这些错误往往不会立刻显现——毕竟软件架构不会立刻崩溃，监控和测试工具也不会将此视为严重破坏。

软件架构漂移

架构漂移（即缓慢且持续的结构化架构侵蚀）就是其中一种典型表现。以大型银行为例，他们在对庞大Java单体系统进行现代化改造的过程中，发现原有架构极其复杂、整个周期须持续数年。加上种种隐藏的架构陷阱，改造工作屡屡停滞。

也就是说，架构问题可能比代码bug更不易察觉，但造成的影响却更为严重。

AI如何助力实现软件架构现代化

但问题并非没有解决办法。

一个令人欣慰的消息是，不理解现代化改造背景的不只是AI，还包括很多开发者和架构师。在同样迷茫的探索中，AI往往能够发挥令人惊叹的作用。

只要让AI根据运行时分析并获取架构上下文，它就能在现代化进程中检测并修复各类架构问题。

只要使用得当，结合运行时上下文加上初步领域驱动结构分析，AI完全可以：

• 抢先检测出架构反模式并予以纠正；
• 提供精准的重构策略；
• 确定修复优先级，帮助工程团队节约时间；
• 厘清复杂的依赖关系；
• 自动修复架构漂移，有效实现系统自我修复。

高效推动现代化改造

运用AI推动架构改造的第一步，在于确定有效的提示词。提示词的质量取决于AI获得的上下文与具象化前提，且直接决定架构改造结果。

那么，行之有效的提示词该是什么样？

1. 尽量具体

不要使用“构建REST API来管理订单”这类模糊的表述，而应包含更具体的架构设计思路：

 “使用Flask和SQLAlchemy构建一个Python REST API来管理订单，应用结构如下：

• 用于处理HTTP请求的控制器层（由Flask实现路由）；
• 用于业务逻辑的服务层；
• 使用SQLAlchemy ORM进行数据访问的存储库层。”

2. 尽量详尽

不要只提供代码逻辑，还应包含非功能性需求。

 “扩展Python Flask REST API以支持运维稳健性与可维护性。具体包括：

• 记录每条传入的HTTP请求及其响应状态。使用Python内置的日志模块记录每条请求的执行时间。日志应采取结构化设计，包含时间戳、端点、状态码和延迟时间。
• 使用 Pydantic 模型在控制器层验证所有传入的请求负载。确保验证错误返回标准化的 JSON 错误响应，其中包含清晰的消息和相应的 HTTP 状态码。
• 在存储库层中，针对瞬时数据库错误实现带有指数退避的重试逻辑。使用 Tenacity 处理重试，避免在业务层重复逻辑。
• 确保所有错误响应遵循一致的JSON模式，包括错误代码、消息和可选的调试详细信息。”

3. 始终保持架构师思维

传达架构设计与目标，包括如何将其融入系统。假定需要为订单系统开发一套模块化的邮件传递系统，其须具备横向扩展能力并可后续拆分成独立微服务，则系统应遵循以下要求：

1）清晰的关注点分离——构建时将代码库拆分成多个明确的层：

   a.控制器层（即Flask路由）：接收并验证邮件发送请求。

   b.服务层：处理业务规则，如速率限制、内容模板和重试等。

   c.存储库层：使用SQLAlchemy管理邮件发送尝试、状态及投递日志的持久化。

2）无状态性：

   a.调用间不维持特定的会话或请求状态。

   b.所有上下文（如发件人ID、邮件内容、标头）必须在每条请求中独立携带。

   c.将所有状态持久化至外部存储（数据库、缓存或队列）中，以维护无状态计算节点。

3）可扩展性与微服务兼容性：

   a.将各主要关注点（如发送队列、邮件渲染、状态跟踪）设计为内部模块，后续可轻松拆分为独立服务。

   b.避免硬编码实现——应为各主要组件（如EmailProvider、EmailQueue、TemplateEngine）定义接口。

   c.通过构建函数或简单的DI容器注入所有服务及存储库依赖项。

4）非功能性需求：

    a.弹性：使用退避策略优雅处理SMTP错误与重试失败。

    b.可观察性：使用请求ID及投递元数据记录所有邮件活动。

    c.可扩展性：通过接口抽象轻松支持多个提供程序（如SendGrid、SES）。”

请注意：提示词代表的就是我们想要的架构，因此务必具体、提供上下文且保证描述全面。

为提示词添加架构上下文

之前我们提到了“添加上下文”，但却一直没有具体论述。

这里我们以vFunction为例，使用这款用于分析应用架构并为生成式AI助手提供结构化重构指引的工具。如此一来，我们将把静态/动态分析与数据科学结合起来以理解应用程序的逻辑域，再反过来借此在复杂的Java和.NET应用程序中发现架构问题。例如：

• 循环依赖
• 反模式
• 架构技术债
• 域边界违规
• 死代码
• 其他

将这些信息输入智能体，即可为其提供编写代码所需要的信息。

分步示例

下面我们将逐步把以上流程走一遍，了解如何为代码助手提供架构上下文。

分析整个应用

先从应用中收集静态和动态数据，这里使用vFunction识别应用中潜在的逻辑域及其边界。这一结果可以识别相关架构问题，例如次优域边界、域间类依赖关系、资源依赖关系、技术债集中的类、循环依赖以及跨域共享代码。之后即可查询分析结果、找到需要立即重构的错误，并提出类似以下问题：哪些域中包含的通用类数量最多？

对一款中型应用及其相互交织的业务域（圆形部分）进行分析，理解其技术债。

审查架构待办事项

下面制作一份按优先级排序的架构待办事项清单，每个条目均包含上下文说明和一条可在Amazon Q或GitHub Copilot等工具中直接使用的提示词。

在AI助手中使用提示词

在向IDE或代码助手发出提示词后，它会理解上下文并帮助拆分上帝类、解决领域污染问题或提供变更建议，尝试提高代码的模块化水平。以上一张截图为例，可以看到关于重构循环流依赖项的建议。

验证并重复

应用变更后重新运行分析，AI系统会显示模块化程度是否提升、哪些待办事项已经解决、哪些尚未解决，再给出下一步重构建议。

通过将这些洞察与大模型相结合，就能建立起一个强大的上下文感知助手，随时为重构中的难题提供指引。

AI——你的软件架构合作伙伴

AI编程只是这项技术的应用方向之一，它更可以成为全面的合作伙伴，帮助我们对现有软件架构做出现代化改造。

通过使用架构感知、基于运行时的上下文来生成高效、一致且精确的提示词，AI有望帮助大家克服遗留技术债、提高代码模块化水平，最终建立起可扩展、云原生的现代化系统。