我工作的第一个项目是做手游电商平台的，整个项目从无到有，团队人员由少到多，几年的时间我们也慢慢形成了比较规范的流程和宝贵的经验。一个面向用户的业务，需求不断迭代，新的业务需求意味着新的技术设计，作为测试开发，我们不仅要保障版本的上线质量，运行质量，还要确保技术设计的正确性以及后续的扩展性，因此需要整理一套可执行，全面的设计评审checklist。
零、研发设计基础要求
- 设计文档符合研发设计模板，此设计模板根据各个业务特点定制，每个设计文档按照模板展开。
- 评审前1天发出设计文档，相关同学进行预审
一、功能方面
1、功能基本流的完整度
思考：对比产品需求与流程设计，是否缺失功能。可以理解为这个是所有正常业务流程。
2、异常流的完整度
思考：如需要调用接口的时候，超时时间设置为多长，超时了如何处理，失败后的处理流程等。
3、设计逻辑合理度
思考：是否影响到其他功能，是否需要兼容。并确定后续的回归范围。
4、可测性及测试成本
思考：各个模块的设计的可测试性及测试成本，即这样设计在后续的测试过程中有没有方法比较方便的验证，如果验证起来非常麻烦，是否在测试阶段添加其他易于验证的手段，比如打印日志。
二、性能方面
1、涉及批量接口，需要单独考虑
2、请求方式是否需要异步
思考：如需要在页面加载不影响主要功能的内容时，可以考虑异步加载。是否有需要做惰性加载？
三、数据库方面
1、表设计是否合理
思考：1）是否能满足设计逻辑。
2）是否需要分库分表。
3）数据是否会快速增长，是否需要定期归档。
2、索引方面是否合理
思考：1）新表索引，是否合理。
2）旧表添加索引，需要结合线上已存在的索引，统一进行评估添加，并且大表的索引需要提前安排流量少的时间执行。
3、字段是否合理
思考：1）设计新表若有冗余字段，是否是强需求必须的。因冗余字段涉及到数据一致性问题。
2）对旧表新增字段，特别是必填字段，旧程序是否兼容，默认值是否可以兼容。
3）对旧表修改字段，旧数据是否兼容，新旧程序是否兼容。
4）字段长度如果能对应上产品需求，一般会设计比需求要求的要冗余一部分。
5）相同字段在不同数据表中是否类型相同。
四、缓存方面
1、是否需要缓存
2、缓存类型是否合理
思考：1）是否会随着时间越来越大。
2）什么时候更新，是否会存在雪崩、穿透、击穿
3、缓存上线
思考：1）是否需要上线前进行预热？需要预热的话预热的设计实现手段是什么。
五、回滚及灰度方面
1、灰度方案选择
思考：1）灰度一般有2种手段，采用升级部分机器，需要考虑新旧程序对数据库及缓存的兼容。
2）业务自己根据一定规则做业务逻辑灰度，需要考虑是否需要用户登陆。灰度的具体范围是什么点。
2、回滚方案选择
思考：设计必须要支持回滚，回滚后数据及缓存是否可以继续兼容。是否需要准备回滚数据处理脚本。
六、安全方面
1、数据存储方面
2、功能权限方面
思考：需求及设计是否已考虑权限控制。如是否会根据不同用户给出不同页面，是否特定用户才能做某类操作。
七、监控及补偿机制
1、重要业务是否有监控
思考：该业务是否自动类型业务，是否核心业务，是则需要考虑相关监控。
2、重要业务的数据补偿机制
思考：该业务是否不允许丢数据，是否需要提供重试任务机制保障等。