目录背景大型重写项目的一部分核心问题人工智能仍然需要领域专家第一步将 RandomNumbers 类引入解决方案使用 Copilot 来识别实际使用情况重写类只保留必需的方法真正的问题在于GetUniqueRandomNumbersCopilot关于异步和性能的建议架构转变从领域到基础设施当你再也看不懂自己的代码时当人工智能真的帮不上忙的时候尝试不同的模型Grok代码库的当前状态使用 Copilot 创建集成测试最终要点参考如果您喜欢此文章请收藏、点赞、评论谢谢祝您快乐每一天。人工智能辅助开发工具通常被宣传为生产力提升工具可以帮助我们理解、重构甚至重写复杂的代码库。但是当代码老旧、编写糟糕且文档不完善时它们的实际表现如何呢在本文中我将通过一个实际示例演示如何在 Visual Studio 2026 中使用 GitHub Copilot 重写遗留 C#/.NET 应用程序的一部分——具体来说是位于系统核心的随机数生成器。这并非一个精心设计的演示而是对人工智能遇到混乱的遗留代码时会发生什么情况的实际展现。背景大型重写项目的一部分这段视频是我即将推出的系列视频的一部分在这个系列中我将重新审视多年前我开发的一个应用程序。在之前的几集中我解释了该系统的总体目标和重写策略。本节重点在于重写旧版应用程序使用的 RandomNumbers 组件。这里的主要目标不是为了风格而重构而是为了理解意图、简化行为并做出在原始代码中从未明确表达过的架构决策。核心问题人工智能仍然需要领域专家这段重写代码提供了一个实际示例展示了如何使用 Copilot 来处理编写不佳的代码。这项练习最重要的结论很简单进行重大重写时开发人员仍然需要对应用程序实际要实现的目标有深入的领域知识。人工智能可以提供帮助但它无法取代理解。在常见的现实场景中这一点尤其如此原开发人员已离开公司。几乎没有相关文件。这段代码“能运行”但仅仅是因为存在一些未记录在案的假设。有些快速技巧只有原作者才能理解。当遗留代码既老旧又编写糟糕时事情很快就会变得非常棘手。第一步将 RandomNumbers 类引入解决方案这个RandomNumbers类是系统的核心组成部分但在最初的设计中它位于一个独立的外部库中。第一个实际步骤是将这个类直接引入到解决方案中以便更轻松地进行审查、测试和重写。查看原始实现代码后立刻就能看出这段代码有问题该课程力求具有多种用途它被设计成可以在假想的未来应用程序中重复使用。它包含许多从未真正使用过的方法。修订版的目标是将课程精简到实际需要的程度。namespace Lottron2000.Infra.Utilities;public interface IRandomNumberGenerator{#region Multiple ItemsListint GetRandomNumbers(int noOfRandomItems, int min, int max);TaskListint GetRandomNumbersAsync(int noOfRandomItems, int min, int max, CancellationToken ct default);Listint GetUniqueRandomNumbers(int noOfRandomItems, int min, int max);TaskListint GetUniqueRandomNumbersAsync(int noOfRandomItems, int min, int max, CancellationToken ct default);#endregion#region Single Itemint GetRandomNumber(int min, int max);Taskint GetRandomNumberAsync(int min, int max, CancellationToken ct default);int GetUniqueRandomNumber(int min, int max);Taskint GetUniqueRandomNumberAsync(int min, int max, CancellationToken ct default);#endregion}使用 Copilot 来识别实际使用情况Copilot 可以帮助解答一个简单但重要的问题实际采用的方法有哪些在这种情况下类中只有两个方法RandomNumbers被调用过。即使是这样基本的洞察Copilot 也需要几分钟才能计算出来——单个问题大约需要 3 到 5 分钟。在实际的改写过程中你可能会遇到 20 到 30 个类似的问题每个问题都需要时间进行分析。这凸显了一个令人不安的事实有时候除了手动理解糟糕的代码之外没有其他捷径可走。人工智能有所帮助但它并不能消除认知成本。重写类只保留必需的方法Copilot 的第一个具体任务是重写该类只保留两个被调用的方法。这种方法效果还不错。新类已在新解决方案中创建快速检查后确认只保留了所需的方法。然而事情一旦办妥更深层次的问题就开始浮出水面。namespace Lottron2000.Infra.Utilities;public class RandomNumbersGenerator : IRandomNumberGenerator{private static readonly ThreadLocalRandom _threadLocalRandom new ThreadLocalRandom(() new Random(unchecked(Environment.TickCount * 31 Guid.NewGuid().GetHashCode())));private Random Random _threadLocalRandom.Value;public RandomNumbersGenerator(){ }public Listint GetRandomNumbers(int noOfRandomItems, int min, int max){ }public TaskListint GetRandomNumbersAsync(int noOfRandomItems, int min, int max, CancellationToken ct default){return Task.Run(() GetRandomNumbers(noOfRandomItems, min, max), ct);}public Listint GetUniqueRandomNumbers(int noOfRandomItems, int min, int max){return GenerateUniqueRandomNumbersInternal(noOfRandomItems, min, max, CancellationToken.None);}public TaskListint GetUniqueRandomNumbersAsync(int noOfRandomItems, int min, int max, CancellationToken ct default){return Task.Run(() GenerateUniqueRandomNumbersInternal(noOfRandomItems, min, max, ct), ct);}private Listint GenerateUniqueRandomNumbersInternal(int noOfRandomItems, int min, int max, CancellationToken ct){ }private void ShuffleT(IListT list, CancellationToken ct){ }#region Single Item Methodspublic int GetRandomNumber(int min, int max){ }public Taskint GetRandomNumberAsync(int min, int max, CancellationToken ct default){return Task.Run(() GetRandomNumber(min, max), ct);}public int GetUniqueRandomNumber(int min, int max){var result GenerateUniqueRandomNumbersInternal(1, min, max, CancellationToken.None);return result.First();}public Taskint GetUniqueRandomNumberAsync(int min, int max, CancellationToken ct default){return Task.Run(() GetUniqueRandomNumber(min, max), ct);}#endregion}真正的问题在于GetUniqueRandomNumbers剩余的方法之一GetUniqueRandomNumbers需要仔细审查。该方法的目的是生成随机数将先前生成的值存储在内存中确保不退回重复件几个问题立刻显现出来执行过程并非确定性的生成 1,000 个不同的数字很容易但生成 1,000,000 个则要昂贵得多。性能和资源使用量会不可预测地变化由于集合共享线程安全是一个值得关注的问题。该方法受 CPU 限制而非 I/O 限制。这引出了一个重要的设计问题这个方法应该采用异步方式吗Copilot关于异步和性能的建议Copilot的指导其实相当可靠随机数生成受 CPU 限制请勿将其async/await用于纯 CPU 工作——它只会增加开销。如果大型请求可能会阻塞调用线程则提供卸载选项例如Task.Run。支持取消和进度报告对于小规模工作负载始终提供快速同步路径。因此行为发生了RandomNumbers显著变化它现在公开了异步/卸载方法大型操作可能需要几秒钟。CancellationToken安全需要A此时该类已不再符合纯领域对象的定义。架构转变从领域到基础设施从概念上讲这个类现在的行为更像是数据库调用文件系统操作一项资源密集型服务因此架构设计决定RandomNumbers从领域项目转移到基础设施项目。完成这项工作后class就变成了瘦身更易读更专注于单一职责当你再也看不懂自己的代码时接下来是 LotteryNumbersGenerator 类。这门课看起来至关重要——但即使作为原作者我也完全摸不着头脑。我无法自信地回答每种方法的作用是什么哪些方法至关重要哪些是多余的或过时的经过近两个小时的调查意图仍然不明。代码中包含太多职责导致难以判断其正确性。这里一个重要的区别就显得至关重要了代码重写不是重构。重构保留了现有行为。重写则需要对代码意图有透彻的理解。否则你可能会以更简洁的形式延续过去的错误。当人工智能真的帮不上忙的时候我尝试使用 CopilotChatGPT 5 mini来讲解课程。正如预期的那样它生成了大量文本——但未必能提供有用的信息。我仍然无法判断移除某些方法是否会破坏系统的其他部分。在这种情况下Copilot 确实帮不上忙——这也很正常。问题出在代码本身。尝试不同的模型Grok出于好奇我尝试了另一种模型Grok代码。我请它解释一个具体的概念WinningNumberPermutation中奖号码排列。这一次解释清晰明了切实可行。简而言之排列逻辑表示的是一组预先计算的、有界的有效彩票号码而不是在彩票环境中没有意义的无界随机值。这种解释实际上就变成了一种规范。有了这种理解我就可以自信地重写这个类并删除旧的冗余代码。有趣的是这一见解来自一个尚未被广泛讨论的模型——而且目前也不需要高级会员资格。代码库的当前状态现阶段建筑外观与原貌已大相径庭一个专注于随机数生成的基准 RandomNumbers 工具。彩票专用逻辑已迁移到更高级别的服务中数据访问被隔离在存储库之后项目间职责划分清晰明确最初的实现方式将所有内容都塞进了一个类和一个项目中。看起来简洁明了但实际上代码混乱不堪。新版本虽然更冗长但却更容易理解。使用 Copilot 创建集成测试接下来我要求 Copilot 为更新后的生成器创建集成测试RandomNumbers。关键限制因素仅进行集成测试不使用模拟测试新项目02_Integration每个公共方法对应一个测试类命名规则_ShouldCopilot 总体上取得了成功但也暴露出了一些局限性它使用旧版 .NET Framework 创建了测试项目。它没有向实用程序类添加项目引用我忘记指定要测试的确切类名了。测试本身通过了而且很简单——但这强化了一个重要的教训。最终要点1. 人工智能不能取代理解尤其是在处理遗留代码时。2. 不同的模型提供非常不同的价值。高级摘要不足以进行架构重写。3. 及时准确地说明很重要。对框架版本、引用或约定的假设将会失败。4. 重写需要意图而不是清理。将重构后的冗余代码带过来就违背了重写的目的。人工智能是一个强大的助手——但正确性、架构和意图的责任仍然在于开发者。如果你正在进行遗留代码的重写工作或者尝试使用人工智能辅助开发你的体验很可能非常相似。这些工具固然令人印象深刻但它们并不能免除我们的思考。参考【第一集——GitHub Copilot AI 代码审查】( https://youtu.be/P26t5EVz70U )【第二集——创建.NET项目和解决方案结构】( https://youtu.be/Vf0yULOHY3I )【第三集——旧代码重写随机数生成器】( https://youtu.be/6DuaW9VjQa8 )如不能打开上面视频参考网址可下载观看https://download.csdn.net/download/hefeng_aspnet/93232242如果您喜欢此文章请收藏、点赞、评论谢谢祝您快乐每一天。