技术评审不只是评审技术

刚开始参加技术评审时，我主要关心方案本身：表怎么设计，接口如何定义，缓存是否需要，性能能不能满足要求。

这些当然是技术评审的一部分。但项目做得多了以后，我发现评审中暴露出来的很多问题，其实并不发生在技术层面。

有人对需求的理解不同，有人不知道系统还依赖另一个团队，有些异常流程从未被讨论，也有一些关键决定只存在于几个人的聊天记录里。技术方案只是把这些问题集中呈现了出来。

写文档首先是在整理自己的思路

一个方案只存在于脑中时，很容易显得完整。真正开始写文档，才会遇到具体问题：数据从哪里来，状态由什么条件改变，失败后是否重试，新旧接口怎样兼容，上线顺序如何安排。

写作迫使思考变慢。原来被一句“这里做一下处理”带过的地方，需要变成可以被别人理解和检查的步骤。

因此，技术文档的第一个读者通常是作者自己。它不一定要长，也不必套用固定模板，但应该让实现方案从头到尾走得通。对于状态复杂的功能，一张状态图可能比几页文字更有效；涉及多个系统时，时序图则能较快暴露调用顺序和异常处理上的空白。

如果文档只能记录已经确定的结论，而不能帮助作者发现尚未确定的问题，它的作用就很有限。

技术人员很容易认为，需求评审已经结束，技术评审只讨论如何实现。但不少返工恰恰来自“如何实现”背后隐藏的需求分歧。

例如，同一个字段在产品眼里可能只是展示信息，在研发设计中却会影响状态流转；一个看似简单的配置项，可能同时涉及权限、历史数据和多个客户端版本。如果只检查代码层面的可行性，方案即使技术上成立，也未必符合最初要解决的问题。

产品、测试、前端和后端参与评审，不是为了让会议显得正式。他们分别掌握不同的信息：产品确认目标和边界，测试补充异常场景，前端确认交互与协议，后端说明数据和系统约束。

技术评审的重要结果之一，是确认大家讨论的是同一件事。

项目中的很多风险并非无法预见，只是没有在合适的时间被说出来。

外部系统不稳定怎么办，数据量增长后方案是否仍然成立，旧版本客户端会怎样处理新字段，上线时某个依赖方没有同步发布会发生什么。这些问题如果在评审阶段提出，可能只需要调整设计或上线计划；到了生产环境，便会变成故障和数据修复。

评审不能消除所有风险。它更现实的作用，是让团队知道风险在哪里、由谁关注，以及发生以后如何处理。

这也是为什么我后来会把上线计划放进技术方案。开发完成并不代表工作结束。配置、数据初始化、依赖顺序、灰度范围、监控和回滚方式，都属于方案的一部分。

系统维护几年以后，代码只能告诉后来的人“最后怎样实现”，却不一定能解释“当初为什么这样实现”。

也许当时有两个方案，最终因为时间、数据规模或依赖条件选择了其中一个；也许一个看起来不够简洁的兼容逻辑，是为了保证迁移期间不影响旧业务。背景消失以后，合理的妥协很容易被误认为随意设计，临时限制也可能被当成长期规则保留下来。

一份有效的评审记录应该保存关键选择和约束，而不只是最终的表结构与接口。这样，新成员接手时不必完全依赖口头讲解，后续重构也能知道哪些条件已经发生变化。

并不是所有需求都需要完整的设计文档和正式会议。改动很小、边界清楚的工作，如果也要求填写大量模板，评审本身就会成为负担。

是否需要评审，可以看几件事：参与方是否较多，状态和数据是否复杂，是否存在兼容与迁移，失败后的影响是否明显，以及团队内部是否已经形成一致理解。

技术评审的目的不是留下“已经评审过”的记录，而是减少那些本可以提前发现的误解和风险。

方案最终仍然要由代码实现。但在代码之前，团队需要先把问题说清楚。