修改大型 .NET 代码库，同时保持高性能和兼容性

## 每次变更都优先考虑热点路径的性能和兼容性 将代码库视为性能关键型基础设施，其行为可能影响大量下游构建。 - 在热点路径中，将运行时效率作为工程决策的最高优先级。尽量减少内存分配，避免可以省去的抽象开销，并选择在规模扩大后仍能保持高效的算法。 - 除非变更明确采用选择加入机制，否则必须保持兼容性。当警告被视为错误时，新增警告、错误或行为变更都可能破坏使用方的构建。 - 保持变更聚焦。遵循周围代码的架构与风格，但当大量新增代码足以证明现代化改造合理时，应使用当前的语言特性。 - 不得引入编译器或分析器警告。应假定正式构建会将所有警告都视为错误。 - 相比推测，优先采用代码库自身的构建、引导输出、示例和测试所提供的证据。 ## 按代码库的风格编写 C#，并在解析时减少内存分配 在自行制定局部风格规则之前，先应用代码库的格式化工具和`.editorconfig`。 - 优先使用固定SDK所支持的当前C#语法，包括能够提升清晰度的集合表达式。 - 在符合代码库既有风格时，使用文件范围命名空间和简洁的`using`指令。 - 遵循代码库的花括号风格，并在引用成员时使用`nameof`。 - 当模式匹配和switch表达式能够在不增加开销的情况下使条件更清晰时，应使用它们。 - 对内存分配敏感的解析应优先使用`Span<T>`、`ReadOnlySpan<T>`、切片以及基于span的`TryParse` API。 - 单字符规范化使用不受区域性影响的字符操作；领域标识符使用代码库指定的领域比较器。普通的非领域标识符使用序数比较。 - 仅对体积小、经过测量且位于热点路径中的辅助函数考虑积极内联。 应根据文件已确立的模式处理可空引用类型： - 新文件使用可空引用类型，且不得禁用可空性分析。 - 明确禁用可空性分析的文件应保留该风格；不要添加孤立的可空注解。 - 已启用可空性分析的文件应使用准确的注解和明确的null处理。 - 优先使用`is null`和`is not null`等基于模式的null检查。 根据更新模式选择不可变集合。对于一次构建、多次读取的数据，使用紧凑的数组支持型不可变集合或冻结查找结构。只有确实需要逐步更新时，才使用持久化不可变列表或字典。当直接循环可以避免内存分配时，不要在热点路径中使用查询管道。 ## 从热点路径开销和新增警告两方面审查变更 审查变更时，应假定其将在广泛使用的构建引擎中运行。 1. 确定每条变更路径的执行频率和数据量。 2. 标记热点路径中不必要的内存分配、重复枚举、查询运算符、可避免的字符串创建以及低效查找结构。 3. 检查解析是否在可行处使用span，并确认比较语义与对应领域一致。 4. 确认集合类型适合其构建方式和访问模式。 5. 查找新增诊断、默认值变更、求值顺序调整、命令行为改变或其他外部可观察差异。 6. 现有行为中的任何新增警告或错误，即使看似有用，也必须视为破坏性变更。 7. 对于用户主动选择新契约的新增选择加入行为，可以允许更严格的诊断。 仔细检查包源配置变更。新增外部源必须有明确理由；如果代码库定义了获准的内部源，应优先使用内部源。除非请求的工作确实需要，否则不要更改固定SDK、包源、共享构建属性或集中式包版本文件。 绝对不要编辑生成的构建输出或由代码库管理的本地SDK目录。当行为、公开API、命令或故障排除指南发生变化时，应更新附近的技术文档。 ## 先构建最小的项目，并从最早的错误开始修复 从足以证明变更组件正确的最小构建开始，仅在代码库完成契约要求时才扩大验证范围。 - 当变更范围局部时，使用代码库标准的安静构建命令构建单个项目。 - 集成验证使用平台对应的全代码库构建脚本。遵守文档规定的超时时间；不得仅因输出安静就取消已知需要长时间运行的构建。 - 不要将构建输出通过管道写入文件。需要持久保存的错误列表时，应使用构建系统原生的文件记录器选项，以保证控制台行为和退出状态可信。 - 审查部分构建错误时，从最早出现的错误开始。后续错误通常是前面错误造成的结果。 - 如果构建无法解析固定SDK，应启用代码库的引导环境，并确认预期的SDK版本处于活动状态。 - 全代码库构建成功后，使用生成的引导可执行文件或引导环境进行下游验证。 - 端到端检查应使用代码库中的示例项目，而不是无关的外部项目。 将构建产物保存在代码库定义的产物目录中。不得手工编辑生成文件来制造构建成功的假象。 ## 测试变更，并运行新构建的命令后再结束 采用能够同时证明变更后行为以及代码库所生成构建引擎的验证顺序。 1. 运行相关单元测试项目；在有帮助时，使用针对变更场景的测试筛选器。 2. 仅当代码库契约或变更范围要求时，才运行完整测试套件。遵守文档规定的运行时间，绝不提前取消仍在正常运行的长时间测试套件。 3. 通过引导环境构建一个具有代表性的代码库示例。 4. 使用帮助输出等无害命令调用新构建的命令行入口点。 5. 确认全代码库构建在没有警告或错误的情况下完成。 6. 重新阅读差异，检查生成文件编辑、未经请求的配置变更、兼容性风险以及文档缺失。 完成工作需要证据，不能只有编译成功。记录已运行的构建、聚焦测试、示例和可执行文件检查，并明确说明无法执行的验证。如果只完成了组件级检查，不得声称已经完成全面验证。