20 个章节 · 支持关键词组合搜索
棕地项目现代化
实践 / 建议棕地项目现代化：先让改变可验证，再扩大自主范围
按工程能力分批，而不是一次性改造 500 个仓
| 现状分组 | 第一笔投入 | Agent 可承担的工作 |
|---|---|---|
| 冷启动不能构建或依赖丢失 | 锁工具链/制品源、补构建说明、隔离必需依赖 | 盘点与接入 MR；暂不承诺自主业务修复 |
| 能构建但测试弱 | 关键入口特征测试、错误路径与最小可运行夹具 | 有明确验证目标的小范围修改 |
| 单仓验证可靠、跨仓不清楚 | 消费者契约、服务目录、版本组合与数据隔离 | 固定组合内的分阶段改造 |
| 验证可靠且可恢复 | 独立验收、有限重试、重建环境与观测 | 低风险任务自主推进到 MR |
先抽样代表工程建立分布：语言、构建工具、运行环境、关键性、依赖、测试、责任和变更频率。 冷门且短期退役的仓可以只补责任与恢复手册；高频核心仓优先补可测试边界。 避免用统一大改造挤占业务交付，把每次真实需求或故障修复作为补能力的机会。
六步改造流水线（建议）
- 盘点：读既有规则与 CI，记录基线失败、缺失依赖、外部状态和个人路径。
- 重建：从干净环境完成 bootstrap 与构建，记录工具链、依赖解析与制品摘要。
- 保护：对本次要改的关键行为增加特征测试，保留现有错误语义、权限与兼容行为。
- 隔离：把时间、随机数、外部 IO、任务调度等做成可控边界，限制改动面。
- 提升：把真正有价值的断言、报告完整性和差量规范接入 CI，已有债务明确登记。
- 扩散：先试一个模块/仓，再同类小批，按失败类型改适配，最后纳入团队标准包。
特征测试用于发现非预期变化；如果旧行为本身就是错误，另设修复 验收标准，不能永远把旧错误固化成规范。 遗留全仓 lint 债务以基线与差量门禁管理，新增高风险问题硬阻断；例外有期限和补偿措施。 不要借接入 AI 一次性升级所有框架、改目录和重写业务，导致无法定位回归来源。
三个优先演练
| 演练对象 | 小范围目标 | 通过证据 |
|---|---|---|
| AppFramework / metadata / SFA | 先切知识消费者，再选一条已确认调用链补契约与回归 | 新库可检索、断链为零；固定版本组合完成正负业务样例 |
| fs-feeds | 校准测试命令及 FSpec 路由/规则版本，保留真实失败 | 故意失败用例使必需门禁失败；跳过、缺报告不能被汇总为 PASS |
| 一类重复技术迁移 | 选一个可明确判断适用性的依赖/测试框架改动 | 前置检查、单仓试跑、独立 CI、人工评审及可回退 patch |
这些是建议演练，不是已执行的公司案例。 技术迁移优先使用 codemod/OpenRewrite 等确定性工具；Agent 负责调查、补适配、分析失败和少量例外。 Uber 的实际经验中，批量 AI 改写测试类未成功，最终用兼容 runner、前置过滤、确定性 recipe 和分批验证完成迁移。 因此现代化项目应允许“不适用/需人工”成为正常结果。
批量改造需要一个活动台账
为每个目标记录发现、适用、不适用、基线阻塞、已生成、验证失败、待评审、已合并、已回滚。 由仓库责任人控制评审并发，按同类 1 个、3–5 个、再扩批的建议节奏推进。 记录失败类型并修复共享 recipe；不要让 Agent 在 500 个仓重复踩同一个环境问题。 一旦出现跨租户/数据损坏、错误通过或大面积基线漂移，停止该批，修复规则后重验。
本节依据： Uber 迁移原文；内部工程基线见证据索引 L3/L4。