程序员如何做「架构评审」：不是走过场，是质量门禁
架构评审是技术团队最重要的决策把关机制之一。
做得好能避免大的技术方向错误，做不好就是走形式。
一、什么是架构评审
架构评审是对技术方案进行集体审查的机制。
不是"汇报"，是"评审"——要发现问题，不是鼓掌通过。
二、为什么要做架构评审
1. 避免重大失误
架构错误代价大，早发现早修改。
2. 集思广益
一个人的经验有限，团队评审能发现单人不注意到的问题。
3. 统一理解
评审后大家对架构理解一致，后续开发不容易跑偏。
4. 知识传承
评审过程是团队学习的机会。
三、架构评审的参与者
1. 方案提出者
讲清楚方案是什么、为什么这么设计。
2. 评审者
资深工程师、技术负责人、相关模块负责人。
3. 主持人
组织会议、控制节奏、确保结论。
四、架构评审的时机
1. 重大架构调整
新系统上线、大规模重构。
2. 技术选型
选框架、选中间件、选数据库。
3. 高风险决策
可能影响系统稳定性的决策。
4. 资源投入大
需要较多开发时间或资源投入的项目。
五、架构评审看什么
1. 方案完整性
- 能否满足需求
- 边界情况是否考虑
- 扩展性如何
2. 技术可行性
- 团队能 hold 住吗
- 时间来得及吗
- 依赖是否可行
3. 风险评估
- 有什么风险
- 怎么应对
- 是否有备用方案
4. 成本效益
- 开发成本
- 维护成本
- 收益是什么
六、架构评审的常见问题
❌ 流于形式
"反正评审就是走过场"——没有意义。
❌ 太晚评审
做到快完成了才评审，发现问题来不及改。
❌ 评审者不认真
看完方案没意见，评审后出问题。
❌ 没有结论
评审完了没有明确结论，不知道是过了还是继续改。
七、一句话总结
架构评审 = 时机合适 + 评审者到位 + 看完整性/可行性/风险/成本 + 有明确结论。