技术方案评审怎么做？设计合理性、实现风险与兼容性

技术方案评审检查的是：设计如何满足已确认的需求，它依赖什么前提，又会引入哪些风险和兼容性影响。 评审对象可以是一页设计说明、接口定义、状态图或原型，不必等到代码写完。

“采用后台线程，支持取消，完成后保存文件”是一段方案概述。要判断它是否可行，还需要知道线程读取哪一份数据、取消如何到达写入操作、成功由谁确认，以及失败后会留下什么。

本文面向个人开发者和小团队，沿用“批量导出CSV”的虚构教学案例。所有设计、状态图和问题记录由作者编写，尚未实现或进行性能、并发、断电恢复测试。本文检查设计逻辑，不将方案评审通过写成程序已经运行正确。

技术方案评审与代码审查的区别

技术评审不是所有项目都必须设置的独立会议。局部改动可以用一份简短设计说明异步讨论；涉及数据格式、认证、并发或不可逆操作时，通常值得更细地审查。

Google工程实践中的审查指南关注设计、功能、复杂度及测试。该资料讨论的是代码审查，本文借用相关检查视角，不把它当成一套正式技术方案评审制度。

先固定需求版本和方案约束

本例以教学需求v1为依据，核心要求如下：提交成功时取得当前筛选结果的数据快照，按ID升序输出；只接受1–5000条；CSV字段为id、name、status，使用UTF-8 BOM；不覆盖已有文件；支持提交正式文件前申请取消；同一窗口只允许一个活动任务；失败须报告并处理本任务临时文件。

这里的5000条是教学设定，不是性能结论。快照包含输出字段的值；只冻结筛选条件、执行时再逐条读取最新数据，不满足这项约定。

评审材料还应列出目标操作系统、数据来源、已有接口、文件格式兼容要求，以及不在本次范围内的内容。本例不讨论服务器任务队列、跨窗口协调及断电后的数据持久性保证。

比较方案时说明代价和适用条件

下面三个候选方案用于展示取舍，没有经过基准测试。

候选二也有尚未解决的成本：快照如何取得一致数据、字段长度是否受限、内存是否可接受，都需要具体数据源及目标环境的证据。记录条数上限不等于内存上限，更不等于界面不会卡顿。

对关键决定，可以采用简短的架构决策记录（ADR）：背景、候选、决定、取舍、状态和重新考虑的条件。Microsoft的ADR指南提供了相应记录建议。不要把所有局部代码选择都升级为架构决策。

数据流检查输入、快照与输出是否一致

本例候选设计分为三步：

1. 界面提交筛选条件，任务协调器占用活动任务名额；重复提交被拒绝。
2. 在数据源能够提供的一致读取边界中取得输出字段快照，检查数量与规则；快照成功建立后，提交才算成功。查询失败或超限时释放任务名额。
3. 后台任务只读取这份独立快照，按约定字段和排序写入自己的临时文件。

快照获取也不能阻塞界面线程。可以在获取期间显示“准备中”；但准备中如何取消、窗口关闭时如何收尾，仍需写入设计和验证计划。

原创候选设计：快照成功建立是提交成功边界；箭头表示数据或控制关系，不代表已实现。

评审接口时，需要核对输入类型、空值、任务标识、返回状态和错误语义。还要明确快照对象的所有权：后续界面操作不能修改后台任务正在使用的同一个可变列表。

取消和完成竞争时如何保证单一终态

“支持取消”至少涉及请求、受理和完成清理三个不同阶段。按下按钮后可以立即显示“正在取消”；只有后台实际停止、完成必要收尾后，才显示“已取消”。

本例建议由一个协调器串行决定终态。它可以通过锁、事件循环或其他同步机制实现，具体方式需要结合框架选择：

• 正式提交前，若取消请求先被协调器受理，则禁止提交正式文件，进入取消收尾。
• 若协调器先获得完成权，则进入短暂的提交阶段；此后取消不能改变终态。
• 正式文件提交成功才报告成功；提交操作失败则报告失败。
• 已取消、已成功、已失败不允许被晚到的回调再次改写。

原创状态示意：写入结束不等于已经成功，提交操作也可能失败；取消申请不等于清理已经完成。

这只能说明候选设计的逻辑意图。还需要通过可控制的测试检查取消恰好发生在提交前后、重复回调及异常清理等场景。单靠阅读状态图，不能证明没有竞态。

如果某次底层写入不能中断，取消响应可能要等它返回。方案应说明检查点和最长阻塞来源；没有测量前，不宣称“立即取消”或保证固定响应时间。

文件提交、错误与兼容性需要单独核对

临时文件不能冒充成功结果

临时文件应属于当前任务，放在适合提交策略的位置；写入成功、关闭成功并通过最终取消判断后，才尝试产生正式文件。磁盘满、权限不足、目标冲突都应进入明确的失败处理。

特别需要核对所用系统接口的覆盖语义。Python的os.replace文档说明了替换目标的行为，因此不能直接把它当成“不覆盖已有文件”的通用实现。先检查存在、再执行可覆盖重命名，也不能消除两步之间的竞争。

本例要求后续实现选用目标平台上可满足无覆盖提交的原语或协议，并补充竞争验证；评审材料不能仅写“原子重命名”就视为该问题解决。原子可见性与断电持久性也是不同保证，本文没有验证后者。

错误清理只处理本任务拥有的资源

清理不能按宽泛通配符删除目录中的CSV，也不能为了重试先删掉已有正式文件。临时文件清理失败时，原始失败原因和残留位置都应保留，不能用一条“已失败”掩盖磁盘中仍有半成品。

文件格式与已有调用方保持一致

CSV的列名、顺序、编码、状态值表示和换行处理都属于兼容性检查。使用标准CSV写入器处理逗号、引号和换行；还应确认消费端如何解释内容。

如果文件供电子表格打开，包含公式样式文本时需单独明确安全与文本保真策略。OWASP的CSV注入说明提示了电子表格解释不可信内容的风险；加引号不自动等于消除公式解释风险。尚未决定的消费端行为应作为问题回需求确认，不能在实现中随意增加前缀、悄悄改变原始值。

评审结论要区分决定与待验证假设

这张表是教学示例。实际评审还需记录负责人、版本和复核状态。阻碍数据正确性的问题没有处理时，不宜无条件通过；可行性实验没有完成时，结论应明确允许推进到什么阶段。

NASA技术评估说明强调评审条件与行动项的处理；其双向追踪说明则可用于理解需求与设计之间的联系。本文采用轻量记录，保留每项决定对应的需求及验证任务。

评审后向实现和测试交接什么

交接应包含设计版本、已采纳决定、接口与状态说明、未关闭风险，以及需要通过实验或测试确认的事项。测试人员可以据此补充取消竞争、提交失败和数据快照用例；但业务预期仍以已确认需求为依据。

实现期间出现新的限制时，回到对应需求或设计重新确认，不让代码中的临时绕过自动成为产品规则。代码审查检查最终实现是否符合这些约定，执行测试再验证它们是否实际成立。

参考资料

• NASA：Technical Assessment

• Microsoft：Maintain an architecture decision record

• Google Engineering Practices：What to look for in a code review

• Python标准库：os.replace

• NASA Software Engineering Handbook：SWE-052 Bidirectional Traceability

• OWASP：CSV Injection

资料核对日期：2026年11月9日。方案和检查表为教学建议，不是已实现产品的功能或性能承诺。