技术评审不只是评审技术

刚开始参加技术评审，我主要看表怎么设计、接口怎么定义、需不需要缓存，以及性能能不能满足要求。

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

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

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

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

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

写文档时，先要让自己把实现方案从头到尾走一遍，不一定要长，也不必套用固定模板。状态复杂的功能可以画状态图，涉及多个系统时，时序图能较快暴露调用顺序和异常处理上的空白。

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

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

同一个字段，产品可能只用来展示，研发却让它参与了状态流转，简单的配置项也可能涉及权限、历史数据和不同客户端版本。只检查能不能实现，很容易漏掉这些理解上的差异。

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

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

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

评审时，还需要考虑外部系统不稳定、数据量增长、旧客户端处理新字段，以及依赖方没有同步发布的情况。这时发现问题，可能只需要调整设计或上线计划，到了生产环境，就可能需要处理故障和修复数据。

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

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

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

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

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

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

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

能在评审时把需求分歧、依赖和上线风险说清楚，后面就少一些返工，没必要只为留下一条评审记录把所有人叫到一起。