遗留项为什么要追踪
评审里总会出现「可以后续处理」的意见。当场能改的直接改掉，改不了必须有归属：建任务、写进台账，或明确决定不做并说明理由。没有归属的遗留项等于没有提出过——几个月后没人记得当初的约束条件，代码里只留下一条没人敢删的注释。
基本信息
| 可当场改 | 直接改掉，不留尾巴 |
|---|---|
| 暂不处理 | 建任务，并在评审评论里贴上链接 |
| 代码内 TODO | 必须带跟踪编号或负责人 |
| 定期回顾 | 把评审遗留项纳入迭代清单一起排期 |
典型使用场景
- 意见涉及大范围重构：先记录、单独立项，不阻塞本次合并
- 依赖尚未就绪的接口：写明触发条件与负责人
- 纯粹的优化建议：标为非阻塞，能顺手做就做
- 与本次改动无关的既有问题：另开任务，避免范围蔓延
- 决定不处理的：回评说明原因，留下决策记录
遗留项的四种去向
- 立即修：影响正确性且改动很小，当场改掉
- 本迭代修：需要独立任务与明确负责人
- 记录待定：等外部条件明确后再决定是否处理
- 明确不做：回评说明理由并关闭，避免反复讨论
TODO 注释写法
TODO 注释写法
// TODO(order-team#1421): 改用批量插入，当前逐条写入在万级数据下会超时
// 团队约定：TODO 必须带跟踪编号或负责人，缺了就要求补齐登记要素
| 要素 | 说明 |
|---|---|
| 改什么 | 一句话说清要改的位置与目标状态 |
| 为何缓 | 说明当前不处理的具体理由 |
| 谁跟进 | 负责人，或明确到某个团队 |
| 何时还 | 目标版本或迭代 |
「回头再说」的评审意见等于没提：要么落地为任务，要么明确放弃，不要留在评论区。
定期扫一遍 TODO 与遗留任务：仍然成立的重新排期，已经不成立的直接关闭。