程序员如何做「架构评审」：不是炫技，是把关
架构评审是对技术方案的把关机制。
好的架构评审让团队少走弯路，差的架构评审让好的方案被否定。
一、架构评审的目的
1. 把关方向
确保架构方向正确，不偏离业务目标。
2. 发现风险
提前发现架构上的问题和风险。
3. 知识共享
让团队了解架构设计，统一认识。
4. 达成共识
让利益相关方对架构方案达成一致。
二、什么时候需要架构评审
1. 新系统立项
新系统开始之前，评审架构方案。
2. 重大重构
系统重构幅度大，需要评审方向。
3. 技术选型重大变更
换技术栈、换框架，需要评审。
4. 跨团队依赖
架构设计涉及多个团队，需要对齐。
三、架构评审的内容
1. 架构设计
- 整体架构图
- 模块划分
- 技术选型
2. 数据设计
- 数据模型
- 数据流向
- 存储方案
3. 接口设计
- 系统间接口
- 接口协议
- 性能要求
4. 容灾设计
- 高可用方案
- 备份策略
- 故障切换
5. 部署方案
- 部署架构
- 扩容策略
- 监控告警
四、评审会议怎么开
1. 会前准备
- 发出架构文档
- 评审者提前阅读
- 明确评审重点
2. 架构讲解
- 讲解架构背景
- 讲解设计思路
- 讲解权衡取舍
3. 开放讨论
- 评审者提问
- 讲解者回答
- 记录问题和结论
4. 给出结论
- 通过
- 需要修改
- 拒绝并说明原因
五、评审者注意事项
1. 以理服人
提意见要有依据，不是"我觉得不好"。
2. 关注重点
架构方向、设计思路、技术选型——这些是关键。
细节可以放到 Code Review。
3. 考虑约束
技术、资源、时间——都是在约束下做决策。
六、一句话总结
架构评审 = 会前准备 + 架构讲解 + 开放讨论 + 给出结论，核心是把关方向、发现风险、达成共识。