域驱动代理

过去几年，我在编码领域（或者更广泛地说，在软件工程领域）大量使用了法学硕士。我多次观察了我可以从中获得的生产力提升，并且我在越来越多的项目中使用了法学硕士。它在绿地项目和小型项目中效果很好。现实情况是，在日常工作中，我们需要将代理引入遗留代码库，这些代码库具有严重的依赖树、强耦合和技术债务积压，其中充满了我们从未接触过的一切。我们很快注意到法学硕士的工作质量可能会急剧下降。故障具有特定的形状。在新建仓库中询问“工作机会状态”字段，您就会得到一个。在一个已经发布四年的系统中请求它，模型会发明一个已经存在三次的概念的第四种拼写，因为代码库本身从未决定哪一个是真实的。它在调用没问题的地方编写一个适配器，或者在适配器就是重点的地方直接调用。其中每一个问题都是关于系统的问题，系统在任何地方都无法回答。模型会猜测，而且经常猜测错误。所以棕地项目很深，技术深度只是第一层。下面是第二个问题：混乱、缺失意义以及没有共同的语言来解决它。这就是模型所属的层。该模型不是需要升级的。代码还没有准备好，而准备工作是我们可以构建的。逐渐地。一点一点。让我向您展示我是如何做到的。这比以前更容易 # 在软件工程之初，有一个也是唯一的：技术债务。这是我们作为开发人员努力实现的目标的自然结果。我们还没有准备好接受未来的业务决策来改变我们当前对代码的看法。我们需要交付，并且快速交付，并付出一些权衡。结果，代码气味变得越来越大。通常的答案是将部分工程预算用于清理：指定 10-20% 的技术预算用于解决技术债务。理论上......在下个季度......预算的五分之一是决定应该改变什么然后将其打印出来的费用，而这两半的价格从来没有相同。决定留下来的费用和原来一样贵。打字就崩溃了。 LLM 将以不再像 2020 年那样的成本来完成清理工作的机械部分（提取的模块、跨两个包的重构、更多的测试覆盖率）。支付技术债务仍然需要时间。它需要的时间少得多，剩下的就是决定性的部分。战略与战术 # 我将工作一分为二，我会借用 John Ousterhout 的《软件设计哲学》中的文字，同时诚实地说我正在扭曲它们。他使用战术和战略来表达编码时可以持有的两种态度：战术编程是立即开始工作，战略编程是在进行时投资于设计。我使用同一对来分割作者身份，因为上面的经济学就是沿着这条线切入的。战略工作就是做出决定：阅读系统，找出必须更改的内容和原因，以及更改是否真正服务于该功能。战术工作是将这一决定写入文件。第一个是需要你头脑中的系统的部分。第二个是便宜的部分。我所做的# 在第一个项目中，我完全参与其中，在第二个项目中，我更像是审阅者而不是实施者。在第一个路径中，我以更通用的方式分析代码库，评估需要实现的更改以及它们与我想要提供的功能的一致性。这些方法的效果是我在每个存储库中创建的 GitHub 问题。然后，我的人工智能系统根据技能和子代理来解决这些问题。技能是一个书面程序：模型在任务匹配时加载的指令标记文件，因此“解决问题”或“重新生成上下文映射”每次都以相同的方式运行，而不是我那天早上碰巧表达的方式。子代理是一个单独的模型会话，具有自己的新上下文和自己的狭隘工作（实施、安全审查、规范审查），报告结果而不是将其整个记录转储到我的记录中。当它们被实施时，PR 就准备好投入使用了。我会参加审核会议，接受更改或要求进行一些改进。我可以逐步做到这一点，关心测试覆盖率和谁破坏了：在变更发生之前，我需要知道系统的哪些其他部分消耗了我正在接触的东西，以及变更是否是他们可以生存的。现在，作为一名软件工程师，我负责协调、计划并创建改进路径。但那时我不需要自己实现它。时间就节省了。 DDD 作为基础 # 剩下了战略性的一半，它的价值与它所使用的语言完全一样。这就是 DDD 的用武之地。DDD 一直是我选择的软件之一，一年后我仍然可以更改。 Eric Eva 提出的方法