作为开发人员，你一定被老板要求过“做个设计评审吧”。那么问题来了，要怎么做设计评审呢？答案非常简单：问你的老板。因为公司风格不同，一定要先明确预期，不要自己猜测这种“一句话需求”。可以先咨询是否有相关的文档和模版，或者他人做的参考。
新人往往惧怕沟通，担心这是能力不足的体现。其实，追根刨底才是一种专业性的体现。
为什么要做设计评审客观来说，因为不信任。当你作为一个新手时，领导需要确认你理解了需求并采用合适的设计思路，保障质量与扩展性的同时还需要确认安全性等方面不出问题。而资深开发，也需要确认了解现有团队整体架构规范。当团队结果一段时间的配合后，会达到一些默契，就可以简化相关流程。同时，涉及多方合作时，也可以在设计评审时，说明配合方式，以及为什么要这样配合。作为实际执行人，每一次发声也是一次个人的分享展示。
我认为的设计评审流程软件工程的课程中有着标准的设计评审参考标准，这里仅谈一下我认为的设计评审流程。
0.组织会议确定参与人员
确认时间、地点
发送相关资料文档
1.需求背景介绍。不要直接贴PRD，要基于分析理解来精简、提炼。尽量通过2、3句话交代清楚背景、目标。比如
WHAT:账号管理系统，维护账号信息、密码管理以及登陆需求。WHY:满足关键信息登录控制需求，引导用户完成注册及后续转化。
2.逻辑视图(依赖关系)用于明确当前功能在整个平台中的位置和职责，以及和不同功能模块之间的依赖关系。
可能有2个纬度
如果是微服务架构，则描述系统间依赖及调用方式(同步rpc/异步mq)，包括基础中间件的引用关系
如果是已有项目内模块，则描述不同模块间的关系
3.过程视图列出核心流程的时序图，讲解用户故事
如果流程中有某个复杂逻辑判断，可以单独添加活动图描述条件分支
4.DB设计一般情况是通过关系行数据库实现数据持久化，需要给出数据库表结构并描述清楚关联关系。如果没有DB规范校验工具，则此环节会review数据库结构是否符合规范。反之，则将DB校验结果列出。
5.数据推演通过用例数据，结合过程视图中的流程对DB操作进行推演，以此反证DB设计的合理性
6.api设计可能是