Design review 设计评审
文章目录
背景
几年前在实习时，我完全没有接触过设计评审。当时的团队采用Scrum开发过程。开发团队采取一个架构师（Architect）和三到四个开发者（Developers）的配置。为了保证开发速度，冲刺订单（Spring backlog）里的大多数任务（Ticket）都有架构师写的详细开发步骤。架构师在团队里负责了大多数的软件设计任务，开发者则专注于将架构师的想法实现。
参加工作后，由于开发领域，开发过程，甚至是公司文化都与我实习过的公司有很多不同。在此期间，我也接触到了相当多的设计文档和设计评审。
2019年，我在开发团队里承担的设计任务也越来越多，写过的设计文档有二三十个。参加的设计评审则是更多。一年下来，我对设计评审，这个软件开发中的一个流程，有了自己的一些看法，下面则是我对设计评审的一个小总结。
设计文档
设计评审，需要首先有设计。这里说的设计就是设计文档（全称软件开发设计文档）。这是在软件开发之前，一种把软件设计思路结构化记录下来的资料。我第一次接触设计文档是在大学的软件工程课上。当时我也在课程项目中写过设计文档，但是却对为什么需要设计文档体会不深。毕竟当时的项目都很小，难度也不大。写设计文档无非是根据模板填充文字的游戏罢了。
但是当项目参与人员众多，开发难度大时，软件设计，作为软件开发的一个流程，被重视起来。我们在实践过程中，尤其是在一些重要的工作上 （比如时间跨度长，需要几个Sprint周期才能完成的工作，或者涉及多个团队，需要跨团队分工协作时），需要先把思路写下来，通过设计评审分享出来，得到相关人员的批准或者承诺后，再进行实现。
也许短期看，写设计文档，走完设计评审流程比直接蒙头实现软件要慢的多。但是一个好的设计可以在长期为产品的开发节省大量的时间。试想一下在有其他团队对你的软件库（Library）或者Web Service产生依赖时你才发现你的代码需要重新设计的情况，这时不仅是自己负责的项目会受到影响，使用你的代码的其他团队的项目也都会受到影响。
设计评审是软件开发的一个重要环节，写好设计文档则是让设计评审成功的第一步。在我看来，一个好的设计文档应至少包括如下几项：
- Problem statement。陈述待解决的问题，以及为什么要解决这个问题，或者说，不解决这个问题的后果是什么。
- Recommended proposal。详细阐明推荐的解决方案，以及Pros/Cons的比较。
- Alternatives。其他可行的解决方案，一般来说解决方案不止一种，也需要有Pros/Cons 对比。能让评审人知道trade-off是什么。
更加详细的设计文档除了上面几项外还会有：
- Background。交代问题的背景，比如总项目的进程，该问题所属项目与总项目之间的关系。
- Term。术语表。通常在抽象度高的讨论中，会用到很多术语以及缩略语。它们应该在术语表里进行定义，以避免歧义。
- Plan。项目的计划。实现过程复杂时，需要分解实现过程，定义每个阶段的需要交付的模块。或者是每个阶段性成果Milestone是什么。
评审
一个成功的设计评审需要以下要素。
- 精简的评审团。只让必要的人参与进来。比如项目负责人，项目的主要贡献者或者受到最大影响的人。他们对设计思路的方向最有发言权，能提出有建设性的意见，而且能最后拍板。邀请不必要的人，会增加讨论中的噪音，以致评审流程变慢。
- 提前制定好的议案。有效率的讨论需要高质量的议案。设计评审的发起人需要准备好评审大会的议案流程，先讨论重要的点，比如一旦敲定就可以让部分项目先开展实现的点。这样接下来的点可以在不阻塞项目进展的情况下讨论。
- Meeting Minutes。及时分享会议记录，其中包括参与的人，何时做出了什么决定或者得到了什么共识。当评审大会需要分几次召开时，会议记录作为之前会议的备忘能让我们避免重复讨论。