领导说做个设计评审吧。
作为开发人员，你一定被老板要求过“做个设计评审吧”。那么问题来了，要怎么做设计评审呢？
答案非常简单：问你的老板。
因为公司风格不同、个人喜好差异，因此一定要先明确预期，不要自己猜测这种“一句话需求”。可以先咨询是否有相关的文档和模版，或者他人做的参考。
新人往往惧怕沟通，担心这是能力不足的体现。其实，追根刨底才是一种专业性的体现。
为什么要做设计评审
客观来说，因为不信任。
当你作为一个新手时，领导需要确认你理解了需求并采用合适的设计思路，保障质量与扩展性的同时还需要确认安全性、可维护性等方面没有缺陷。
而资深人员，也需要确认了解现有团队整体架构规范。
当团队结果一段时间的配合后，会达到一些默契，就可以简化相关流程。
同时，涉及多方合作时，也可以在设计评审时，说明配合方式，以及为什么要这样配合。
作为干饭人，每一次发声都是一次个人的分享展示。
我认为的设计评审流程
软件工程的课程中有着标准的设计评审参考标准，这里仅谈一下我认为的设计评审流程。
0. 组织会议
- 确定参与人员
- 确认时间、地点
- 发送相关资料文档
1. 需求背景介绍。
不要直接贴PRD，要基于分析理解来精简、提炼。尽量通过2、3句话交代清楚背景、目标。
比如
WHAT: 账号管理系统，维护账号信息、密码管理以及登陆需求。
WHY: 满足关键信息登录控制需求，引导用户完成注册及后续转化。
INDICATOR: 2W+历史账户待迁移，预期每日新增100+
LIMIT: 安全性隔离，无法与LDAP直接通信
2. 逻辑视图(依赖关系)
用于明确当前功能在整个平台中的位置和职责，以及和不同功能模块之间的依赖关系。
可能有2个纬度
- 如果是微服务架构，则描述系统间依赖及调用方式(同步rpc/异步mq)，包括基础中间件的引用关系
- 如果是已有项目内模块，则描述不同模块间的关系
3. 过程视图
列出核心流程的时序图，讲解用户故事
如果流程中有某个复杂逻辑判断，可以单独添加活动图描述条件分支
4. DB设计
一般情况是通过关系行数据库实现数据持久化，需要给出数据库表结构并描述清楚关联关系。如果没有DB规范校验工具，则此环节会review数据库结构是否符合规范。反之，则将DB校验结果列出。
5. 数据推演
通过用例数据，结合过程视图中的流程对DB操作进行推演，以此反证DB设计的合理性
6. api设计
可能是http接口(可以通过swagger等工具编写)，或者相关interface。
除了确保接口设计符合规范外，这个环节最重要的点其实是各合作方达成一份契约，认可后就可以按照此设计分别进行开发实现。比如:前端通过mock页面开发，测试团队开始编写接口测试脚本。
类图
一般不做强制要求，针对资历较浅的同学会增加把控。如果应用了复杂设计模式，可以特殊说明
部署方案
- 明确各模块依赖关系及发布部署顺序
- 确认配置项变更
- 确认数据变更，包括数据库脚本等
- 预估硬件资源
风险项
提早暴露风险，包括
- 技术风险，比如新技术使用
- 业务排期
- 安全性
问题
注意，这里不是抛出问题，讨论答案，而是列出不同选项和优劣性对比，让与会者给予建议。
感想
分享自己在设计过程中的思考，以及遇到的问题。自己做了哪些判断和取舍。
其他
会议组织者需要把控进度，做好记录。