领导说做个设计评审吧。

作为开发人员,你一定被老板要求过“做个设计评审吧”。那么问题来了,要怎么做设计评审呢?
答案非常简单:问你的老板。
因为公司风格不同、个人喜好差异,因此一定要先明确预期,不要自己猜测这种“一句话需求”。可以先咨询是否有相关的文档和模版,或者他人做的参考。
新人往往惧怕沟通,担心这是能力不足的体现。其实,追根刨底才是一种专业性的体现。

为什么要做设计评审

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

我认为的设计评审流程

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

0. 组织会议

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

1. 需求背景介绍。

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

WHAT: 账号管理系统,维护账号信息、密码管理以及登陆需求。
WHY: 满足关键信息登录控制需求,引导用户完成注册及后续转化。
INDICATOR: 2W+历史账户待迁移,预期每日新增100+
LIMIT: 安全性隔离,无法与LDAP直接通信

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

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

可能有2个纬度

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

3. 过程视图

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

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

4. DB设计

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

5. 数据推演

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

6. api设计

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

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

tech-review-00

类图

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

部署方案

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

风险项

提早暴露风险,包括

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

问题

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

感想

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

其他

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

Welcome to my other publishing channels