在软件包很多的大型单仓库中修改代码并测试

## 编辑前先找到软件包和入口点的位置 - 确定工作区布局、已发布的软件包、原生组件、测试套件、示例、文档和维护脚本。 - 找到主要软件包的源码树、编译产物、命令行入口点、服务器入口点和构建入口点。 - 更改行为前先追踪相关入口点；不要仅凭文件名推断归属。 - 编辑嵌套文件前，阅读从仓库根目录到目标目录沿途所有适用的 `README.md`。 - 将生成产物和依赖目录仅视为用于搜索的证据。应修改其源文件或生成器，而不是直接编辑生成文件。 ## 保持构建产物为最新，并选择局部或完整构建 - 切换分支或初始化状态不确定的工作区后，运行完整的引导构建，确保依赖软件包的产物为最新版本。 - 反复进行源码或集成测试工作时，除非软件包的监视构建已在运行，否则应在编辑前启动它。 - 仅修改文档、只读调查或仅分析 CI 时可以跳过监视模式，但要记录原因。 - 如果更改只在一个软件包内，使用针对该软件包的构建；如果工作跨越多个软件包或更改原生代码，使用完整构建。 - 对于类型错误，如果专用类型检查能提供同等证据，应优先于完整构建。 - 任务完成后，停止由你启动的所有监视进程。 ## 选择与开发或生产模式相符的测试 - 选择与开发或生产行为以及预定的打包器或运行时实现完全匹配的测试命令。 - 运行集成测试前重新构建受影响的源码；陈旧的编译产物会使结果无效。 - 先运行范围最窄的相关测试文件或名称模式，只有失败情况或更改影响面要求时才扩大范围。 - 使用相同的命令、模式、功能标志和环境变量名复现 CI。细微的模式差异也可能改变解析结果和快照。 - 如果主张涉及软件包解析、打包、启动或浏览器行为，不要用方便的单元测试代替集成测试。 - 当功能标志隐式启用某项行为时，应使用该标志测试常规套件，而不能只依赖旧的专用套件。 ## 编写按条件等待、不用固定时长的测试 - 使用仓库的测试生成器及其非交互式参数，使夹具和测试工具配置遵循本地约定。 - 优先使用带断言、基于条件的重试辅助工具，而不是固定时长的休眠。固定延迟速度慢，而且仍容易发生竞态。 - 用受支持的重试并断言模式替换已弃用的轮询辅助工具。 - 优先使用实际夹具目录，而不是大型内联文件映射，使测试更接近真实项目且易于维护。 - 对于模式专用测试，当测试工具要求延迟启动时，应在手动启动服务器前执行模式守卫。 - 在测试的同步边界内控制预取和导航状态；避免使用会恢复缓存状态并触发失控工作的历史记录操作。 ## 保存测试和构建的输出，不重复运行 - 一次性捕获测试或构建的完整输出，然后搜索并总结已保存的输出，不要使用不同筛选条件重复运行同一套件。 - 对于超过约 500 行的文件，先搜索相关符号，只读取其周边范围。 - 只有在确认生成行为确有必要时才搜索生成目录；不要将其作为主要来源浏览。 - 在运行下一次构建前批量完成相关编辑，并使用能够证明当前假设的最快检查。 - 在一次调查期间缓存远程状态响应，从多个角度分析保存的响应，而不要反复获取。 - 保留准确的失败输出、命令、模式和环境，作为下一诊断步骤的证据。 ## 按相同条件重现 CI 失败，并先于审查意见修复 - 如果仓库提供状态分析工具，应使用该工具，并确定当前检查的是当前分支还是明确指定的更改请求。 - 除非证据要求采用其他顺序，否则按以下顺序处理阻塞性失败：构建、格式化或 lint、类型，最后是测试。 - 在被证伪前将失败视为真实问题。已知的不稳定行为只是调查背景，不是忽略失败的许可。 - 使用相同的 CI 模式和环境标志复现问题，尤其是在存在不同打包器或运行时路径时。 - 对于模块解析或构建图失败，运行常规的模式专用集成命令，使真实的软件包图得到执行。 - 将 CI 失败与审查意见分开，先解决阻塞执行的证据，并保留对已复现内容的简要记录。 ## 把功能标志同时接入构建和运行时代码 - 当用户打包的代码使用新功能标志时，将该标志添加到其公共类型、验证模式定义和构建时注入点。 - 如果预编译的运行时代码使用该标志，还要通过每条相关服务器或工作进程路径接入运行时值。 - 不要假定面向用户代码的构建时注入能够控制预编译运行时的内部行为。 - 将条件模块加载放在编译时 `if` / `else` 分支中，使死代码消除能够移除无法到达的依赖项。 - 在受限运行时中，将用于防护不受支持平台导入的标志强制设为 `false`。 - 将运行时专用导入保留在其指定入口模块中，并通过该模块的公共外观公开所需行为。 - 使用专用运行时信号区分正在运行的开发服务器和调试构建；通用环境标签可能同时描述两者。 - 任何新增的非标准入站请求头都要标记为需要安全审查，除非入口层会将其移除或进行身份验证。 ## 不把机密信息写进日志，身份验证失败时停下 - 除非环境变量值是文档明确说明的测试模式标志，否则应将其视为敏感信息。 - 绝不要在共享日志、审查文本或示例中打印、粘贴、提交或放置令牌、密钥、Cookie 或机密值。 - 匹配 CI 的变量名和模式，但不要内联其值。如果缺少必需的机密信息，应停止并通过获批渠道请求提供。 - 记录设置步骤时使用占位符，绝不要提交本地机密文件。 - 如果由于签名代理、密钥提供程序或硬件保护凭据不可用而导致源代码管理身份验证失败，应停止并请用户将其解锁。 - 未经明确批准，不要更改远程协议或地址、重复失败的操作，也不要尝试替代身份验证绕过方案。 ## 发布更改请求或评论前先确认权限 - 创建或编辑远程更改请求、议题、讨论或评论前，确定贡献来自内部分支还是外部分叉。 - 代表用户写入内容前，验证仓库的贡献政策和用户的授权。 - 如果授权不足，不要冒充维护者或发布完整的远程内容。可以提供技术事实、审查用户编写的文本，并指向由用户控制的提交途径。 - 仅在验证条件后，才可在狭窄范围内应用文档所述的例外。 - 除非用户明确认定新建的更改请求已可供审查，否则应将其保持为草稿状态。 - 远程写入需要明确限定范围；本地分析和复现并不表示已获得发布许可。 ## 把工作拆成小步，每步确认后再继续 - 将大型任务拆分为输出可独立检查的小步骤。 - 进入下一步前，使用与风险匹配的方法验证每一步：检查、格式化、lint、类型检查、单元测试、集成测试、构建或运行时观察。 - 如果正确的验证方法不明确，应在声称该步骤完成前询问。 - 提交前，对更改的文件运行与仓库提交钩子所用配置相同的格式化器和 lint 工具。 - 审查最终 diff，检查是否存在无关编辑、生成噪声、机密材料以及缺少测试或文档的情况。 - 未说明支持更改后行为的证据，不得报告完成。 ## 发现陈旧的原生二进制文件和不一致的快照 - 查找源码映射可能需要明确的运行时标志，而且不同编译器的源码路径可能不同；应测试已知的路径形式。 - 比较测试与生产环境的堆栈跟踪时，应考虑当前工作目录。 - 切换分支后，如果行为与源码矛盾，应怀疑陈旧的原生二进制文件；通过获批的引导路径刷新由依赖关系管理的产物。 - 对于编译器内部错误，只移除受影响的增量编译缓存，并在上报前只重试一次。 - 对原生语言代码使用官方格式化器；除严格限定范围的内联测试模块外，优先使用以仓库根目录为基准的导入。 - 快照输出可能随标志和运行时实现而变化，因此只在目标 CI 作业所用的完全相同环境中更新快照。 - 在文档代码块中，编辑后重新计算显示行数，并确认每个高亮都指向预定语句。