5 年经验面试：技术方案评审总是走过场，你怎么让它真正起作用？
面试怎么回答
评审走过场通常是因为文档只写做什么不写为什么、会前没人看、评审人不知道看什么、结论没人跟进，以及什么都评审导致疲于应付。我会先分级，只有新业务域模型、核心链路改造、引入新组件、影响多个下游的口径变更才正式评审，小改动走代码 Review；用统一模板要求写清目标、数据量和时效、备选方案和取舍、模型设计、下游影响、成本、上线回滚和校验方案；文档提前发出，评审人在文档里留评论，会上只讨论争议点；给评审人一份检查清单，比如粒度主键、重复建设、分区、增量、倾斜、口径一致性、监控；结论分通过、有条件通过、不通过，修改项有负责人；重要方案上线后回看，用来改进清单。我也会培养骨干做评审人，而不是什么都自己拍板。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多团队都有方案评审会，但常见的情况是：会前没人看文档，会上作者讲半小时，大家点头，会后照常写代码，上线后才发现分区设计不合理、口径和别的表冲突。面试官想看你能不能让评审真正拦住问题，又不变成拖慢进度的官僚流程。
评审为什么走过场
- 文档质量差：只写了「做什么」，没写为什么这么做、考虑过哪些方案；
- 会前没人看：现场才第一次看到，只能提一些表面问题；
- 没有明确的评审重点：大家不知道该看什么；
- 评审结论没有约束：提了问题也没人跟进；
- 所有事都要评审：小改动也开会，大家疲于应付，重要的方案反而得不到关注。
怎么改
- 分级：不是所有改动都评审。新的业务域模型、核心链路改造、引擎和组件引入、影响多个下游的口径变更才需要正式评审；小改动走代码 Review；
- 统一的方案模板：背景和目标、数据量和时效要求、备选方案和取舍理由、模型和分层设计、对下游的影响、资源和成本估算、上线和回滚计划、数据校验方案；
- 会前必读：文档提前一两天发出，评审人在文档里留评论，会上只讨论有争议的点，会议时间控制在一小时内；
- 评审清单：给评审人一份检查要点——粒度和主键是否清楚、是否重复建设、分区和存储设计、增量逻辑、数据倾斜风险、口径是否和指标字典一致、监控和告警；
- 明确结论：通过、有条件通过（列出必须修改项）、不通过；修改项有负责人，上线前确认；
- 上线后回看：重要方案上线一两个月后回顾，当初的担心是否发生，用来改进评审清单。
负责人自己的角色
- 不要变成「所有方案都要我拍板」，培养骨干做评审人；
- 鼓励不同意见，评审会上新人提的问题也要认真对待。