程序员如何做「技术方案评审」：不是挑刺，是优化

技术方案评审是团队最重要的质量把关机制之一。

开得好能避免大坑，开不好就是走过场。

---

一、技术方案评审的目的

1. 发现问题

方案有没有漏洞？有没有更好的方案？

2. 统一理解

团队对齐对方案的理解，避免后续开发跑偏。

3. 分担责任

评审通过后，团队对方案共同负责，不是某一个人的决定。

4. 知识传承

评审过程是团队学习的机会。

---

二、评审前准备

1. 提前发出方案

评审前 1-2 天发出，让评审者有时间看。

不要现场才发，没人会认真看。

2. 明确评审重点

这次评审重点是什么？是架构还是细节？

让评审者知道关注什么。

3. 控制方案长度

方案不要太长，10-15 页 PPT 或 3-5 页文档。

太长没人看完。

---

三、评审会议怎么开

1. 讲清楚背景

先讲清楚要解决什么问题，为什么要做这个。

不是讲技术，是讲问题。

2. 讲方案设计

用图，不用文字。

架构图、流程图、数据流图。

3. 讲权衡取舍

为什么选这个方案？放弃了什么？

评审者关心的是"为什么"。

4. 开放讨论

不是"汇报"，是"讨论"。

鼓励提问，鼓励不同意见。

---

四、评审者的职责

1. 提前看方案

评审前要看过方案，不然现场没法深入讨论。

2. 问问题

不是"讲得不错"，是要问清楚有疑问的地方。

3. 给建议

从自己经验出发，给更好的建议。

4. 做决定

评审后要有明确结论：是通过、需要修改、还是拒绝。

---

五、常见错误

❌ 评审变成汇报

"我来讲一下方案"——一直讲，没人问问题。

❌ 评审者不提前看

现场看，现场问，浪费时间。

❌ 没有明确结论

评审完了说"我们再想想"——等于没评审。

❌ 只关注技术细节

架构、方向没对齐，细节对齐了也没用。

---

六、一句话总结

技术方案评审 = 提前发出方案 + 图优于文字 + 开放讨论 + 有明确结论。