作为开发人员，你一定被老板要求过“做个设计评审吧”。那么问题来了，要怎么做设计评审呢？
答案非常简单：问你的老板。
因为公司风格不同，一定要先明确预期，不要自己猜测这种“一句话需求”。可以先咨询是否有相关的文档和模版，或者他人做的参考。

新人往往惧怕沟通，担心这是能力不足的体现。其实，追根刨底才是一种专业性的体现。

为什么要做设计评审

客观来说，因为不信任。
当你作为一个新手时，领导需要确认你理解了需求并采用合适的设计思路，保障质量与扩展性的同时还需要确认安全性等方面不出问题。
而资深开发，也需要确认了解现有团队整体架构规范。
当团队结果一段时间的配合后，会达到一些默契，就可以简化相关流程。
同时，涉及多方合作时，也可以在设计评审时，说明配合方式，以及为什么要这样配合。
作为实际执行人，每一次发声也是一次个人的分享展示。

我认为的设计评审流程

软件工程的课程中有着标准的设计评审参考标准，这里仅谈一下我认为的设计评审流程。

0. 组织会议

1. 确定参与人员
2. 确认时间、地点
3. 发送相关资料文档

1. 需求背景介绍。

不要直接贴PRD，要基于分析理解来精简、提炼。尽量通过2、3句话交代清楚背景、目标。
比如

WHAT: 账号管理系统，维护账号信息、密码管理以及登陆需求。
WHY: 满足关键信息登录控制需求，引导用户完成注册及后续转化。

2. 逻辑视图(依赖关系)

用于明确当前功能在整个平台中的位置和职责，以及和不同功能模块之间的依赖关系。

可能有2个纬度

1. 如果是微服务架构，则描述系统间依赖及调用方式(同步rpc/异步mq)，包括基础中间件的引用关系
2. 如果是已有项目内模块，则描述不同模块间的关系

3. 过程视图

列出核心流程的时序图，讲解用户故事

如果流程中有某个复杂逻辑判断，可以单独添加活动图描述条件分支

4. DB设计

一般情况是通过关系行数据库实现数据持久化，需要给出数据库表结构并描述清楚关联关系。如果没有DB规范校验工具，则此环节会review数据库结构是否符合规范。反之，则将DB校验结果列出。

5. 数据推演

通过用例数据，结合过程视图中的流程对DB操作进行推演，以此反证DB设计的合理性

6. api设计

可能是http接口(可以通过swagger等工具编写)，或者相关interface。

除了确保接口设计符合规范外，这个环节最重要的点其实是各合作方达成一份契约，认可后就可以按照此设计分别进行开发实现。比如:前端通过mock页面开发，测试团队开始编写接口测试脚本。

类图

一般不做强制要求，如果针对资历较浅的同学会增加把控。应用了复杂设计模式，可以特殊说明

部署方案

1. 明确各模块依赖关系及发布部署顺序
2. 确认配置项变更
3. 确认数据变更，包括数据库脚本等
4. 预估硬件资源

风险项

提早暴露风险，包括

1. 技术风险，比如新技术使用
2. 业务排期
3. 安全性

问题

注意，这里不是抛出问题，讨论答案，而是列出不同选项和优劣性对比，让与会者给予建议。

感想

分享自己在设计过程中的思考，以及遇到的问题。自己做了哪些判断和取舍。

其他

会议组织者需要把控进度，做好记录。