意义、价值：
设计评审的价值不仅体现在保证设计质量上，也体现在促进设计人员之间相互交流和学习，以及给予指导上，既能提升高级开发、设计人员的设计能力，也能熟悉更多业务，看清系统全貌。
设计评审的目的是改进设计质量。项目可以运行，但并不一定意味着它是正确的。在软件开发中越早发现问题，修复的成本就越低。
沉淀优秀的设计经验，沉淀设计问题经验。
反例：没有做好设计评审的后果
（1）设计质量差：团队内系统设计水平参差不齐，这种情况并不能保证所有人都可以独立做出高质量的设计。而没有经过严格评审的设计，往往存在很多问题。
（2）团队内代码接手困难：没有经过评审的设计，其细节逻辑往往只有编写者自己清楚。在需要其他人员补位的情况下，团队往往发现代码接手困难。
（3）高级开发的能力也提高速度缓慢：在没有实施良好设计评审制度的团队，无法得到细节上的指导，在出现问题后也无法及时改正。
现状
1、低效的设计评审反馈，无针对性反馈。
2、我把别人的设计驳回了，打的分低了，是不是影响我们之间的关系？
3、设计评审时检查点容易出现遗漏
设计评审学习材料
微软：https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff647464(v=pandp.10)?redirectedfrom=MSDN
架构设计评审指导：https://www.codeproject.com/Articles/20467/Software-Architecture-Review-Guidelines
正确的设计评审心态
设计永远有进步的空间。
众人拾柴火焰高，我的反馈（无论大小）可以让你的设计更加完善。
我们谈论的是设计，不是你的职业能力，这个沟通中没有任何感情色彩。
高效设计评审反馈
低效反馈示例：
这个设计很一般，我看不懂它。
这个设计感觉很复杂，你为什么不能把它设计得简洁一点？
谁想出来要设计这个功能的，根本就不该花费时间来做这个。
业务流程图不够清晰明了。
接口调用关系不够细致不够清晰。
数据结构有点儿复杂。
这样的反馈除了贬低他人，没有任何实质性的作用。它会挫伤士气，不但不会让提供这个反馈的人看起来很聪明，反而会因为反馈没有任何信息量让反馈者看起来很不专业。
如何反馈改善设计
问题就像是白纸上的一个黑点，所有人都很容易发现别人的问题。
但是所有设计方案都经过设计人员思考的，之所以白纸上会有这个黑点，设计人员可能有他自己的道理。
有效的设计反馈，不需要跳出来指出黑点，而是理解背后的原因，然后探究如何改善设计。
高效设计反馈的4个步骤
1、直接反应
(你看到一个具体的设计的直观反应)
比如，“我感觉这个数据库表的关系设计有点复杂”。直接反应的反馈是是一个正确的开始。
2、鉴别问题
（指出一个你使用这种设计实际遇到的问题，或者你担心用户会遇到的问题）
鉴别问题这一步是设计反馈至关重要的一步，因为提供反馈的人和设计人员需要统一意见，看当前设计方案究竟有哪些问题。
比如,"这个数据库表关系涉及到6张表的关联查询，如果这么设计可能会导致：
理解困难：复杂的数据库关系设计会使其他开发者难以理解和维护。如果一个表的关系设计非常复杂，那么在理解和解决问题的过程中，会花费更多的时间和精力。
性能问题：复杂的数据库关系设计会导致查询性能下降。在执行查询或获取数据时，需要更多的计算资源和时间。
3、理解问题：开始询问和理解为什么设计人员会做这样的决定。
比如,"你可以给我讲一下你为什么要采用6张表，做关联关系进行查询吗"
如果一个问题看起来非常简单，但是却没有按照常规的方法来处理它，多数情况是你可能还没有理解清楚整个问题的上下文，而不是对方还没有考虑过。这个时候应该更多地询问和理解问题，而不是急于提供任何反馈。
4、提议：理解清楚设计问题的上下文和决策背景以后，尝试提出一个合理的解决方案来改善设计。
比如，“我明白了，当前几张表涉及到一对多，多对多的关系，所以你才这么设计。你是否考虑过把A表和B表合并，C表和D表合并”？
“你是否考虑过”是一个非常好的开放式建议方式。如果设计人员已经考虑过，那么这个对话就回到理解问题的阶段，要继续讨论。
如果设计人员没有考虑过，那么设计人员则可以考虑如何采纳这个解决方案。
反馈者不一定必须做出提议。在一个设计反馈的对话中，只要能鉴别出问题，就已经对设计人员很有帮助了。
经过对话，如果双方能够把问题清晰地定义出来，那么这已经足够让设计人员带着这些反馈进一步去回炉自己的设计。
一个存在问题的设计不一定都需要改进方案，当前的设计可以是最佳的解决方案。设计永远都是在各种冲突中做权衡。如果当前的设计已经是最佳的方案，那么这段设计反馈的对话的作用在于确认问题，深入讨论，确认当前方案已经是最佳。
设计审查的机制
事项 | 角色 | 动作 | 事后动作 |
【文档编写】 编写设计文档 | 设计人员 | CheckList打钩确认自己的设计是符合检查项要求的 | 自查通过后，通知技术经理，并提交自己的checkList 打钩清单 |
【组织会议】 组织召开设计评审会议 | 技术经理 | 邀请本次设计评审相关人员参加评审告知会议时间、地点 | 会议前提前告知需要评审的设计文档、和相关材料（如：需求说明书、原型设计） |
【会议开场】 需要简要说明设计人员对需求的理解，和待审查的内容，重申会议目标。 | 技术经理 | 会议围绕着“发现可能存在的缺陷和问题”进行，而不应该陷入无休止的讨论之中 | 确认所有评审员对材料是否理解一致 |
【设计讲解】 按照设计文档对设计进行讲解 | 设计人员 | 对照需求讲解设计 | @技术经理 对本次会议中大家提出的反馈进行记录 |
【评审决议】 在会议最后，评审小组就评审内容进行最后讨论，形成评审结论 | 所有评审人员 | 按照check list或其他议题表决 接受（通过）、有条件接受（需要修订其中的一些小缺陷后通过）、不能接受和评审未完成（继续评审） | 评审会议结束之后，评审小组提交相应的评审成果，如问题列表、会议记录、评审报告或评审决议、签名表等。 |
【问题跟踪】 会议结束，并不意味着评审已经结束了。因为评审会议上发现的问题，需要进行修正，技术经理或协调人员要对修订情况进行跟踪。 | 技术经理 | 验证作者是否恰当地解决了评审会上所列出的问题，并决定是否需要再次召开评审会议。 | 修改后的产品发给所有的评审组成员，获得确认。所有问题被解决，修正工作得到确认后评审结束 |
【沉淀设计案例】 沉淀错误设计案例和优秀设计案例 | 技术经理 | 标记设计文档中的优秀设计片段 | 提交到设计案例库 |
CheckList
CheckList 同样需要设计人员按清单挨个打钩确认自查完成，而不是把工作抛给设计审查人员。
维度 | 检查项 | 审核类型 |
完整性 | 所有的功能需求与非功能需求是否都体现在了设计中? | 驳回 |
是否使用部门统一的模版？ 部门统一文档列举的内容较全面，包含从版本号、接口设计、拓扑设计等所有需要思考的内容，避免设计时遗漏造成的返工 | 驳回 |
每项功能的描述是完整的吗？ 系统功能设计是否能够覆盖所有已确定的软件需求项？ 软件所有功能点是否都可以追溯到相应需求没有遗漏？ | 驳回 |
不完整、易变动或潜在的需求项是否都进行了相应的设计分析，对各种设计限制是否做了全面的考虑？ | 打分 |
是否有漏掉的输入、输出字段或条件？ | 打分 |
复杂性 | 设计中是否增加了不必要的功能是否为未来的变更进行了过度设计? | 打分 |
某个类的方法是否既执行了修改又执行了查询？ | 打分 |
API或方法的参数是否超过了3个？ | 打分 |
易测性 | 每项功能都是可以被测试的？是否易于测试或如何测试？ | 打分 |
对那些非功能特性（性能、兼容性、安全性等）如何测试？ | 打分 |
所有的设计目标（性能、容量、兼容性等）是可以通过测试结果来衡量的 每一部分的设计是否都可以追溯到软件需求的定义，包括功能需求项和非功能需求项。 | 打分 |
模块化（组件化） | 设计中是否采用了复用历史模块组件，或本次设计中有复用? | 打分 |
系统模块间松耦合而模块内部又保持高度一致性、稳定性（强内聚力）是系统架构设计中要侧重考虑的内容，而高耦合度或低内聚力的系统是很难维护的。 | 打分 |
组件的功能和接口定义是否正确？ 文档描述是否清楚，包含正确的硬件接口、通信接口设计、用户接口设计等。 | 驳回 |
数据结构、数据流和控制流的定义是否正确？包括：模块输入数据、输出数据及局部数据的全部细节。 | 驳回 |
是否为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述？ | 打分 |
是否功能、接口和数据设计具有可测试性、可预测性？ 如要为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定的测试 | 打分 |
每个模块的大小合适吗？是否存在过大的模块？ | 打分 |
是否通过隐藏实现细节、强制构件接口定义、不使用公用数据结构、不让应用程序直接操作数据库等降低程序的耦合度？ | 打分 |
是否通过分解或合并模块以减少信息传递对全局数据的引用，并降低接口的复杂性？ | 打分 |
模块结构是分层的，层次的深度和宽度适当吗？ | 打分 |
可靠性 | 出现异常情况时，系统如何响应？ | 打分 |
系统崩溃时会出现什么问题，是否做了预防？ | 打分 |
系统设计是否保证不存在单点失效？ 系统关键部位是否都有备份机制或故障转移或处理机制？ | 打分 |
对不能在部门开发平台部署项目、数据库、中间件等，应明确高可用架构部署方案，并能够实现多机热备 | 打分 |
出异常时如何告警，是否定义清晰了告警级别，告警描述 | 打分 |
规范性 | 技术选型和架构是否符合部门技术规划要求？ | 驳回 |
是否符合API设计规范？ | 打分 |
是否符合数据库表设计规范 | 打分 |
安全性 | 接口/数据是否有权限设计？当前接口应该具备怎样的权限 | 打分 |
敏感数据是否加密存储，是否脱敏返回报文 | 打分 |
设计合理性 | 是否合理地划分模块和模块结构完整性、类的职责单一性、实体关联性和状态合理性等？ 是否对不同的设计方案作了说明与比较？ 是否清楚地阐述了方案选择的理由和结论？ | 打分 |
设计结果的稳定性 | 以设计维护不变的时间来衡量，稳定性越高越好。是否会因为用户需求的变化或现有设计的错误或不足，必须修改设计？那么修改范围的大小和次数就是影响软件设计质量重要因素。 | 打分 |
设计的清晰性 | 涉及目标描述是否明确，模块之间的关系阐述是否清楚？ 业务逻辑是否准确并且完备？ 清晰的设计也是重用性的基础。 | 驳回 |
结构简单性 | 模块的深度、宽度、扇出和扇入是否适当？ 系统的模块结构的宽度、深度、扇入值和扇出值，是衡量系统的复杂性的简单标准指标 力求做到单入口单出口的模块。 | 打分 |
结构和数据的一致性 | 给出的系统设计结构和数据处理流程是否能满足软件需求规格说明中所要求的全部功能性需求？ 模块的规格及大小划分是否和功能需求项以及约束性需求项之间保持一致？ | 驳回 |
依赖性 | 系统的所要设计的子系统在整个软件环境（或在大系统中）中所处的地位、作用及其与同级、上级子系统之间的关系描述是否准确。 | 打分 |
高性能 | 当前的设计如何保证程序的性能 是否恰当的使用了缓存？ 是否使用到了索引？ 是否进行了多线程设计？ | 打分 |
扩展性 | 当业务规则变化后，程序是否基本不做改动？ 而当业务量猛增时，可以横向扩展部署更多的应用服务器，提高对客户端的响应速度 | 打分 |
数据库设计 | 数据字典设计是否不缺项，结构设计设计完整（数据实体），视图完整（主外键，表于表数据关系）？ | 驳回 |
对于系统使用的数据库种类、数量、读写分离等设计是否合理？思路是否清晰明确？ | 打分 |
数据库逻辑结构划分正确，字段命名，类型，取值范围，精度定义正确无误，主外键定义正确，同一数据元素无二义，无自相矛盾 | 打分 |
设计充分满足数据查询，检索，新增等情况下的性能指标要求 | 打分 |
软件接口设计 | 系统的接口设计能完全涵盖软件内部、外部的不同部分的联系，接口定义明确，无重大遗漏 | 驳回 |
接口单元发起方和接受方逻辑关系正确，输入，输出参数的数量，类型和顺序能够匹配，接口实现技术方式正确无误 | 打分 |
系统接口的数据结构设计详细，能够详细说明各类参数的度量单位，取值范围，类型，符合软件编码的要求 | 打分 |
评审注意事项
明确自己的角色和责任。
熟悉评审内容，为评审做好准备，做细做到位。
在评审会上关注问题，针对问题阐述观点，而不是针对个人。
可以分别讨论主要的问题和次要的问题。
在会议前或者会议后可以就存在的问题提出自己的建设性的意见。
提高自己的沟通能力，采取适当的、灵活的表述方式。
对发现的问题，能跟踪下去。
